[HECnet] Re: PyDECnet additional network objects

That's certainly a good API structure. There's a bit of history here. The original API (the "module" one) is tied very closely to the internal machinery of the NSP layer, not surprisingly. And that's basically asynchronous: messages are queued and sent on their way, other messages are received, and the state changes as needed. Then there is the "connector" API, which I created as a wrapper around pipes and messages on those pipes, for use by applications constructed as separate processes. It's also designed to be simpler, especially the basic pipe structure which is optimized for handling a single connection. So while the NSP internal API treats connect as a "send message on its way" request, with the accept or reject delivered in a separate step, the connector has an "exchange" notion where a message expects a response and the API call completes only when the response arrives. So the exercise is to make that model apply to accept as well. I should also document more clearly that the connector API is the preferred one, with the others (the low level JSON messages over pipes, or the module level API) discouraged. As I said, the module API does apply to applications that need to reach into the guts of PyDECnet, like NML. If someone wanted to write a DECnet MIB listener for PyDECnet, that would likely want to be a module also for the same reason. But things like FAL or PHONE or FINGER are better done with connectors; if multiple DECnet connections are needed, async connectors are best. PMR is an example of that. The timeout produces an internally generated disconnect message, so from the application point of view it would see a receive that delivers the disconnect, just with a different reason code than, say, a remote application doing a disconnect request. Also, disconnect and reject (sent or received) make the connection disappear as a side effect, the handle is no longer valid after that point. So it turns out that accept is the only case where we have a state change not already accompanied by a message. paul