-
Notifications
You must be signed in to change notification settings - Fork 24
Internal Architecture
(this page is WIP)
For a background as to what WAMP is, please see here.
wampy models WAMP concepts as distinct Python classes, i.e. Peers, Sessions, Roles, Messages and Transports, and then passes WAMP messages through these layers when required. 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, but as expected, it does add complexity for contributors.
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.
3rd party applications should subclass and define new methods decorated with wampy implemented WAMP roles to be useful. The base Client will then REGISTER these roles using the private _register_roles method. The base Client used on its own is pointless (unless you enjoy watching WAMP setup and teardown being processed?).
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 for users to subclass and make apps with.
For contributors, note that some of the WAMP protocol is actually implemented in the Session object. This just surrounds the handshake behaviour, else the middle finger response - and I want to look again at these exceptional cases.
I'll now go into more detail. Assume we have an app that subclasses Client and defines or implements all WAMP roles.
Client defines start and stop, which are easily called when you context manage the Client instance, else you can instantiate it and call these methods yourself - but what happens under the hood?
...
...
...