Can't sleep, so spending more time with the manager interface. Interestingly, it seems that pyst has a fairly low-level assumption that just doesn't match the manager interface: namely that all events should be dispatched asynchronously to registered handlers. The problem is that certain actions produce a response, then a sequence of events in order that are only referenceable because they immediately follow the response and precede a closing event.

That is, to handle these types of action-responses the code should look like this: readResponse() readStatusUntilStatusFinished(). Without binding the two together you can't, for instance, watch for the closing of the particular channel you just opened, as you have no way of knowing if a particular opening channel is the one you created, or one that someone else created.

Of course, I might be misreading the section in the wiki where it says there are two contexts in which events occur, or missing something in pyst for handling the second case... it is late after all.

[Even later] Okay, it looks like the API is such that to handle this you need to look up the generating command and see if it expects follow-on events. In looking into fixing that it seems that there's nothing in the pyst code that handles multiplexing/demultiplexing queries (i.e. it only ever has one query in-play at a time that I can see). Maybe it is time to try another interface as others have suggested.

[Even later still (6am)] I'm obviously missing something. I've created a sub-class that uses callbacks and events to multiplex the queries, but somehow the mirage of data-filling events have shimmered out of existence. Obviously need to give my brain a rest, since it's not producing anything functional at the moment.