On Mon, 12 Feb 2007, Mike Fitzpatrick wrote:
>
> The idea of a .ivoamsgrc directory was intended simply to be a startup
> file/ directory mechanism. The thought being that each app could write
> it's own "capabilities database" file indicating the messages it handles,
> preferred type, of transport, task launch command, etc. Other apps
> could read the same DB file to decide whether/how to send messages.
> These would be static files updated perhaps only with a new version of
> the software. For startup, another file would keep track of who is
> 'connected' and in a world where users manually launch tasks every
> few seconds this normally would be manageable. Firing up a "system'
> of multiple tasks (e.g. a small pipeline or an alias for multiple GUI
> tasks) could well have the syncronization problems you mention.
The simplest approach (this thing is supposed to be simple right?) would be to somehow (external to the messaging facility) start up an app, and have it connect to the bus. All the apps needs is to know how to connect, e.g, a string port specification like "user-at-host:port", which could be passed in various ways, such as on the command line or via the environment, perhaps with a session default. Then the app can tell the bus or another client everything about what its capabilities are. No files are required.
The issues of what apps are available and how to start them on local or remote hosts, how to dynamically fire up an app which isn't running yet in response to a client request, etc., is getting into the general issue of execution frameworks and is not required at the level of a simple protocol such as this is supposed to be. In any case, this can be addressed as a separate issue.
My impression with the simple inter-tool protocol was that 1) one would start up the message bus ("hub" or whatever; maybe it is already running); 2) various apps would connect and register, telling what class of app they are and what their capabilities are; 3) a client could then talk to the app.
> Perhaps a .whatever directory as a local capabilities database (similar
> to the .plastic file) and a runtime registry (hub, embedded functionality,
> etc) of some kind is the simplest compromise?
Perhaps (although things start to get more complicated as noted above). If so, a single file might be simpler. This would be read only by the bus/hub upon startup, then everything else can be done at runtime. A system wide default could be provided.
> I'm still interested in ideas about how we keep the message contexts
> separated, i.e. how do I avoid seeing *your* data on *my* window if
> we're both on the same machine?
Sessions solve this problem, e.g., "user-at-host:port" or maybe "user-at-host:session" with the obvious defaults, where "host" is the head or login node (this reduces to localhost in the simplest case). Sessions can be public, per-user, per-session-per-user, etc. The usual thing is to identify the session in the head process and then propagate it on the command line to every process which participates. If an app is started up manually and wants to join a session, one just needs to know what the session is called and this can still be specified on the command line. (OpenRTE and D-Bus do exactly this sort of thing for example).