[HECnet] PyDECnet setup

[Brian Hechinger]

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
>
>