On Nov 18, 2021, at 11:29 AM, Brian Hechinger
<wonko at 4amlunch.net> wrote:
On 18/11/21 16:11, Robert Armstrong wrote:
Brian
Hechinger <wonko at 4amlunch.net> wrote:
The only thing I'd really do is create/update/delete circuits ..
The thing
is, I'm assuming that any such changes via NCP would only be temporary. Unless Paul
implements a way for pyDECnet to rewrite it's own config file, then the next time you
reboot or restart any changes would be lost. Is that what you're expecting? That
pretty much kills any utility in this feature for me.
My plans don't have me caring at all about what (if any) NCP interface there is.
I'd want to use an HTTP/TCP API. Actually, my API needs could be handled by a
completely separate process or just an extra endpoint bolted onto pydecnet's API
without actually tying into what's currently going on with the API.
Speaking of the API: I've gone through several iterations on that, and I'm still
not happy with the current one. The first one was a custom protocol over Unix domain
sockets. The current one is bolted onto HTTP, with JSON lines as the way to encode
requests and responses.
The JSON bit is also how the session layer API works (if you look in application/mirror.py
you'll see that). There the data streams go over pipes, i.e., independent streams
asynchronously flowing in either direction.
The big defect with HTTP as the building block is that it's a request/response
protocol, so I end up with this ugly kludge of polling for server output. So I think the
right answer is (a) keep the JSON encoding, but (b) run that over a separate connection,
not HTTP, but instead just a full duplex data stream. That way when the server has stuff
to send it just sends it. The connection oriented (stream mode socket) connection ensures
the server knows if the client goes away. Unix sockets or TCP, I don't think it
matters a whole lot.
The request/response bit works well enough for state queries and also for hypothetical
"set" operations. But it's just wrong for the session layer API, which I
want to expose. And the same problem shows up in the MOP Console request, as is rather
obvious when you try to decipher the sample application and the documentation for that
feature. The full duplex connection I mentioned would cure that problem.
Obviously this is an incompatible change, but I figure there aren't very many API
users right now and the change would be easy to implement.
paul