-
Notifications
You must be signed in to change notification settings - Fork 24
Internal Architecture
wampy models WAMP concepts as distinct Python classes, i.e. Peers, Sessions, Roles, Messages and Transports, and then passes WAMP messages through these layers. This is done either synchronously (when it can) or via a shared queue when between green thread workers. Either way, wampy tries to manage it solely by an abstracted MessageHandler class.
The MessageHandler is pluggable, meaning any other application or library can exploit wampy.
And yes: async networking is driven by green threads and not asyncio. There are good reasons for this.
For contributors wanting to read their way into wampy, the Client Peer base class is the best route in. This class is designed to be as dumb as possible (but I'm not suggesting you are!) and it has only knowledge of the parameters it's instantiated with and then the WAMP Session it inevitably must start. It is fundamentally intended to be subclassed by 3rd party applications which must then implement new methods decorated with wampy implemented WAMP roles to be useful. The Client will then REGISTER these roles using the private _register_roles method. The Client used on its own is pointless.
Registration of Roles is a part of the WAMP protocol. wampy looks for methods on the Client that are decorated with Roles once a Session has begun and does this by inspecting your application class instance at runtime. _register_roles will only be called once your app receives the WELCOME message from a Router.
The Client object is not part of wampy's WAMP implementation - that is in the MessageHandler. The Client is just a dumb wrapper of everything to subclass.
...
...
...