Restrict scope of Local Message Transport
bilderbuchi opened this issue · comments
In #24, Benjamin remarked
Also, I thought the whole deal of the LMT Node concept was to have it fully local, independent of zmq and network infrastructure, e.g. with queues. As far as I understood queues in python, they are all inside one process, which would be fine for that purpose.
My reply:
Initially yes, but then it turned out that zmq can also do the "local" stuff (ipc, inproc), so it seems good to add that to the LMT options. Maybe we should limit LMT to queues and zmq inproc, and if a node is in LMT, it consequently has to live in one process. What do you think?
Originally posted by @bilderbuchi in #24 (comment)
So, to make it easier to specify the network structure, should we limit the scope of LMT to threading queues and zmq inproc ? Both? Either? Something else that should also be added?
The aim is that we restrict LMT locality more than planned, to one process, so the options are ones that work in one process.
Do we need to decide that yet?
Can't we design the rest and then look, how much can be "local"? (Single process will work, that we know)
Or does anyone require multi process local message transfer?
Yes, we have it in mind, and we are able to allow in a single process, therefore we can check "local mode available".
Now we can continue with the core workings and then revisit this topic.
I would need something for writing #24. But I agree to postpone. I'll find a defensive formulation and add a todo note, and we solve this later.
Yes, I agree, I think we should work on the DMT stuff, and once that is set up (or at least properly defined), we can include the LMT in-process comms.
As for a defensive wording, you could scrap all connections between Node and LMT/DMT, and only put a statement about the LMT/DMT types separately.
I have put LMT on "notional" status and added notes to that effect. I also only retained queues and zmq inproc in the list of LMT options.
Closed by #24.