Usability: listen for jobs coming to multiple workers at once

[vibraphone]

It would be nice to be able to listen for a job coming in on any of several workers. That way a process could start a "handshake" worker to answer metadata queries (like directory listings or whether a given file can be loaded) and another "session"-based worker that contains a model or mesh loaded into memory which might require several operations.

The issue is that the session-based worker will be tagged and thus not respond to requests without extra work from the client.

[robertmaynard]

Am I correct in thinking what you want is the ability for a worker to in itself be a quasi broker? Or do you just mean the ability to have multiple remus::worker::Worker instances within the same process?

[vibraphone]

Am I correct in thinking what you want is the ability for a worker to in itself be a quasi broker? Or do you just mean the ability to have multiple remus::worker::Worker instances within the same process?

I would be happy with either, but the former (use 1 kernel modeling session to contain multiple client sessions where possible) would be nice. Not all modelers support that, but they should all support "stateless" metadata queries in addition to session-based operations.

[robertmaynard]

I think the second one will be the easiest for the short-term. The ability to write a worker/broker in theory wouldn't require that much work on the worker side, but I will have to verify that the server handles that use case properly.

We should iterate over how a worker/broker interacts with the session concept and see if the best way forward is to add a WorkerSessionBroker to remus.