Initial work to start encapsulating individual transactions. While currently it just moved the current transaction tracking logic out of the Dialog class, it opens the door to handling different kinds of transactions without messy branching logic, tracking state (setting up a callback to know when 180 arrived, for example), and properly supporting cancelling (send an appropriate CANCEL message).
Also fills in the server/client subscription example so that it actually sends arbitrary messages back and forth.
Next step is filling in some more transaction support to get a nicer API for the server side - support something in line with aiohttp's websocket support to handle incoming dialogs, map exceptions to error codes, and wrap responses for nice server code.
Initial work to start encapsulating individual transactions. While currently it just moved the current transaction tracking logic out of the Dialog class, it opens the door to handling different kinds of transactions without messy branching logic, tracking state (setting up a callback to know when 180 arrived, for example), and properly supporting cancelling (send an appropriate CANCEL message).
Also fills in the server/client subscription example so that it actually sends arbitrary messages back and forth.
Next step is filling in some more transaction support to get a nicer API for the server side - support something in line with aiohttp's websocket support to handle incoming dialogs, map exceptions to error codes, and wrap responses for nice server code.