Closed oberstet closed 7 years ago
Now, with above, we might not only have Session
follow an observer pattern, but also Client
, so a user could observe lifecycle events on the Client
, such as "on_transport_connect" and such.
We have a first working version of above level of API in the "echo client" example now
High-level WAMP user API
The high-level and recommended API for users of WAMP with AutobahnJava on Netty (means, headless server backend components) would look like this:
We need a WAMP client for talking to Crossbar.io, but that client first needs transports and authenticators
There might be different transportsbe used by a client and the client will use one transport depending on a configurable (re-)connect policy.
For the PoC, we only need anyonmous auth, which is trivial, because the session sends HELLO with realm, but authid/authrole left blank, and the router will always and immediately respond with // a realm/authid/authrole assigned, usually "authrole==anonymous" and realm being the requested one (if it exists).
Of course the main thing is needed as well, the session object:
Now we create a WAMP client providing the transports and authenticators above the client will connect over the first working transport (under a configurable (re-)connect policy) and then begin a WAMP opening handshake joining the realm given, and announcing the list of authentication methods from the authenticators
The following future return will fire when the client finally will not (re)try to connect anymore, and hence the client program usually will exit. until the future fires, the client might connect // and (auto-)reconnect one or multiple times
The client program exits with a return code != 0 whenever the client was deliberately and orderly shutdown. when the client ended with error, eg because the client failed to connect (gave up on retrying).