Applications Messaging Standard

[Doug Tody]

On Fri, 16 Feb 2007, Mike Fitzpatrick wrote:
> On 2/16/07, Doug Tody <dtody at nrao.edu> wrote:
>> One could go one step further and make the "well known port"
>> configurable by some means such as an environment variable or command
>> line argument (with a fixed built-in default).
>
> Note that something like this is required for the same user to have
> multiple 'sessions' on the same machine, otherwise they would always
> connect to the one hub bearing their name.

Sessions could be just a variation on the concept of "user".

> A (future) extension might
> be to allow a list of users access to a particular hub (e.g. via some other
> env variable), this would allow for an app to be shared amongst users
> (insert some clever server example here)

Sometimes one does want to share a resource among "users", even in
a single human user desktop scenario.  We probably don't want to get
into such features at this point, but it nice to have a scheme which
is flexible enough to support such things.


On Fri, 16 Feb 2007, John Taylor wrote:
> This does sound pretty good, though as Alasdair has pointed out it transfers
> some of the complexity from the hub to the client.  Our philosophy with
> PLASTIC has always been to make life easy for clients even if we make life
> harder for hubs.  If we are going to require a client to be able to do direct
> socket programming, then I see fewer benefits in having multiple wire
> protocols.  Why not just pick (e.g.) XMLRPC and be done with it?  Then you
> could scan through the ports using the XMLRPC library and when you get a
> connection just call a "getUser()" method to decide whether it's the right
> hub.

There should be a single protocol for connecting - something simple -
but it is still better I think to have the option of multiple
protocols for messaging once connected.  Otherwise we limit flexibility
(layering) and risk getting locked into one technology (didn't we
already cover all this?!).

> As Doug says, in most cases you'll get the right port first time
> anyway.  In fact, one could go further an eliminate the hub and go peer to
> peer....

Both direct connections and producer/consumer are important.  It is best
to allow for both.  That is why we quote the word "hub".

> each application picks a port in a defined range to host its own
> xmlrpc server.  When an application wants to discover its peers it scans this
> range, and should easily detect whether the port belongs to a suitable
> application.  If the application is going to have to scan a list of ports
> already, I don't see that this is much of an extra burden in return for
> removing the need for a hub.

You have lost me here.  What is a "peer" in this case?  I think you
just have one session and everything connects to it.  It is still
good to have apps connect directly to the messaging system, whatever
it happens to be, and let the messaging infrasructure worry about
how to make apps talk to each other.  Lets not rule out the future use
of real messaging infrastructure by assuming that there is none and
everything is just a direct peer-to-peer socket connection.

> My only unease about it is my use case of wanting to use the messaging system
> from very simple environments such as IDL.

I think this is way overstated - I see people doing all kinds of complex
things such as SOAP with IDL (or IRAF, whatever).  If nothing else, with
a C-based environment, all you do is write a messaging plug-in.

 	- Doug