You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It would be nice if the connection object could have some methods to retrieve connection details such as the address or domain.
They are indeed values provided by the user during connection initialization but may be useful later in the application runtime.
They could be saved by the application somewhere but retrieving them directly from the connection object would offer a central
place of storing them, instead of having them stored twice, one copy in the connection object and another in some application data structure. That would probably require additional code to ensure that both copies are in sync.
Also, the domain option is optional and can be derived from service. It would be nice to retrieve that derived domain instead of having to rewrite the logic to extract the domain from the service.
Describe the solution you'd like
As per package`s client example
const{ client, xml }=require("@xmpp/client");constdebug=require("@xmpp/debug");constxmpp=client({service: "ws://localhost:5280/xmpp-websocket",domain: "localhost",resource: "example",username: "username",password: "password",});// returns "ws://localhost:5280/xmpp-websocket"xmpp.getService()// returns "localhost"xmpp.getDomain()// returns "example"xmpp.getResource()// returns "username"xmpp.getUsername()// Not sure about this one// returns "password"xmpp.getPassword()
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
It would be nice if the connection object could have some methods to retrieve connection details such as the address or domain.
They are indeed values provided by the user during connection initialization but may be useful later in the application runtime.
They could be saved by the application somewhere but retrieving them directly from the connection object would offer a central
place of storing them, instead of having them stored twice, one copy in the connection object and another in some application data structure. That would probably require additional code to ensure that both copies are in sync.
Also, the
domain
option is optional and can be derived from service. It would be nice to retrieve that derived domain instead of having to rewrite the logic to extract the domain from the service.Describe the solution you'd like
As per package`s client example
The text was updated successfully, but these errors were encountered: