Applications Messaging Standard

[Tony Linde]

The obvious answer to this in the windows environment is the registry: the
hub writes its info there when installed and everyone knows where to look
for it. If we're looking at more than one hub app then a new one installed
on a client machine overwrites the info left by the previously installed
one. In the linux arena, which I believe lacks any such central organising
entity, we could use the previous suggestion of a file left in an obvious
place.

Another option, which I *think* might work in both environments is to create
a new mime type with the hub app 'registered' (whatever that means in linux)
as the handler for that mime type. Plastic apps store their information in
files of that type and then look for the app which handles that mime type
and throw their config files at it (if it is running or invokes it first if
not). Would that work?

T.

> -----Original Message-----
> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On 
> Behalf Of Doug Tody
> Sent: 15 February 2007 05:12
> To: Mark Taylor
> Cc: apps at ivoa.net
> Subject: Re: Applications Messaging Standard
> 
> Hi Mark -
> 
> Thanks, I see better now what your motivations are for this mechanism
> (John did say "user-friendly" which is why I thought user 
> interface had
> something to do with this).
> 
> I can see where an automatic auto-connect mechanism such as you
> describe could be convenient, but it is unusual.  When software tries
> to get smarter than whatever drives it this often leads to problems,
> making the software harder to use in some cases; it is better to
> tell it what to do.  Hence we use explicit command line arguments,
> environment variable triggers/defaults, and so forth.
> 
> Off-hand I am not sure how best to solve a problem like this. 
>  A simple
> approach might be to require at least an environment variable,
> possibly with an optional command line override, to trigger the
> connection attempt and provide connection information.   Defining a
> standard API would also provide a way to hide whatever is required,
> but would require more than just a wire protocol.  We might also
> consider whether a simple, general naming service would be worth
> defining for this sort of thing (XPA, being based on the X server,
> which is unique for a user session, has this by the way; it supports
> user sessions, distributed execution, and authentication - of course
> it is also obsolete technology, and a bit platform specific).
> 
> > could you give an explicit scenario for how you envisage a client
> > application could bootstrap its connection to the messaging system?
> > Your story about a UI transparently autogenerating 
> arguments seems to 
> > describe a skeleton for this but I don't know how you
> > see the details being filled in.
> 
> It should be easy if the connection information can be optionally
> provided on the command line when an application is started.  One just
> passes an opaque string containing the necessary connection info.
> Something which knows what to do with this information is also
> required: either a library with a standard API, or we have to
> say something public about how to parse the connection info.
> Multiple sessions, distributed execution, etc., are easily supported.
> An environment-based approach is similar and in fact they are often
> combined.  This solves the problem for the application, but puts it
> off on the "session manager" which has to spawn the hub/bus and pass
> the info.  This is no problem so long as we have something which
> serves this purpose, and it is the more general approach, but it
> does require more than the simple auto-connect mechanism.
> 
>  	- Doug
> 
> 
> 
> On Wed, 14 Feb 2007, Mark Taylor wrote:
> 
> > On Tue, 13 Feb 2007, Doug Tody wrote:
> >
> >> Hi John -
> >> 
> >> On Tue, 13 Feb 2007, John Taylor wrote:
> >>>> BTW, scanning the recent messages I still see a lot 
> about dot files
> >>>> etc.  This is an implementation issue; platform specific 
> issues such
> >>>> as dot files in U*nix can be dealt with by the 
> implementation, and
> >>>> do not have to be addressed by the standard protocol.
> >>> 
> >>> Yes and no.   How one goes about getting the information 
> required to 
> >>> connect could be part of the protocol.  You've already 
> mentioned passing 
> >>> this in on the commandline when you start an application. 
>  Another (and 
> >>> arguably more user-friendly) way would be to put this 
> information in a 
> >>> well-known location on the file system where client 
> applications can find 
> >>> it.
> >> 
> >> The information content and how it is used in operations could be
> >> part of the protocol; how it is stored externally is part of the
> >> implementation.  User interface issues such as providing a 
> file-based
> >> configuration mechanism which the user could edit is an 
> implementation
> >> issue; a different implementation could store the same information
> >> in a different fashion.  That is not to say that it is not 
> important,
> >> just that it is important to separate the two concerns.
> >
> > I don't think John is talking here about a configuration 
> file which the user 
> > would edit (see below for what I think he is talking about).
> >
> >> Specifying connection information on the command line when 
> an app is
> >> started is not normally something one would do in a user interface,
> >> rather such arguments would probably be autogenerated transparent
> >> to the user, when the actual user interface (e.g., a CLI, some GUI,
> >> etc.)  starts up the applications participating in the session.
> >
> > This model can work if the the "actual user interface" in question 
> > understands which applications it can start up will/might 
> participate in the 
> > messaging conversation and can transmit information to them 
> about how they 
> > should connect to it.  But I don't see how it
> > can operate if applications are started up from some 
> third-party environment 
> > such as /bin/sh or javaws.
> >
> >> This is runtime information used to tell apps how to dynamically
> >> connect to a session; it is hard to even see how to reliably pass
> >> such information via files, even if we ignore issues such as could
> >> occur in a distributed or heterogeneous environment.
> >
> > What is hard to see here?  The idea is that a service (the "hub")
> > writes information (such as a port number or URL) in a file 
> at a well-known 
> > location (~/.ivoa-messaging) which describes how clients 
> can connect to it. 
> > The file effectively acts as a very simple naming service; 
> messaging-aware 
> > applications can read the file to find out how they should 
> connect to the 
> > current messaging session.  When the
> > "hub" shuts down it removes the file.  In this scenario the 
> location and 
> > format of the file are part of the protocol not part of the 
> implementation 
> > because participants in the protocol need to locate
> > and read it to bootstrap their connections.  Admittedly this
> > can't be easily extended to, say, multi-user scenarios and so it
> > may be that it's insufficient for the requirements of 
> whatever messaging 
> > system we want to come up with, but "ignor[ing] issues such 
> as could occur in 
> > a distributed or heterogeneous environment" I don't see any 
> problem with it; 
> > as you may not be surprised to hear, it is exactly what is 
> done in PLASTIC as 
> > well as a number of other systems providing informal interprocess 
> > communication I could name.
> >
> > I feel we may have some implicit misunderstanding or disagreement
> > about how connection to a messaging service can work here.  Doug,
> > could you give an explicit scenario for how you envisage a client
> > application could bootstrap its connection to the messaging system?
> > Your story about a UI transparently autogenerating 
> arguments seems to 
> > describe a skeleton for this but I don't know how you
> > see the details being filled in.
> >
> > Mark
> >
> >
> 

http://www.Taglocity.com Tags: IVOA, apps