I'm not getting to my work any time soon so I'll check back with you to
see what the state of the API is.
-brian
On 18/11/21 18:06, Paul Koning wrote:
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