Applications Messaging Standard

[Tony Linde]

> ...  Can a "$HOME/.ivoamsgrc" directory

Just one quick comment on this point - we're getting problems with plastic
apps using this type of resource. Doing a demo the other day on a (WinXP)
machine configured by the department (and so not changeable) we kept getting
'profile storage space exceeded' messages from the OS. This because all the
apps were using $HOME/.xxx directories as scratch space: this area in
Windows is for profile information not general storage. We need some way
that users can point to some other 'home' directory for AR/PLASTIC apps.

T.

> -----Original Message-----
> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On 
> Behalf Of Mike Fitzpatrick
> Sent: 09 February 2007 17:14
> To: Mark Taylor
> Cc: apps at ivoa.net
> Subject: Re: Applications Messaging Standard
> 
> On Fri, 9 Feb 2007, Mark Taylor wrote:
> 
> > On Fri, 9 Feb 2007, Doug Tody wrote:
> > 
> > > Hi Mark -
> > >
> > > I think we are actually saying the same thing.  If we define a
> > > standard inter-tool messaging protocol and implement it on top of,
> > > e.g., D-Bus, you client does not talk directly to D-Bus, 
> it talks to
> > > an implmentation of the defined messaging standard which 
> just happens
> > > to use D-Bus, MPI, Ice, or whatever internally.  It is 
> not a compliant
> > > implementation unless a standard interface is presented 
> which isolates
> > > the client from the underlying messaging infrastructure used.
> > 
> > good, I'm quite happy with that.  In that case I don't think there's
> > much call for discussion here about what underlying messaging 
> > infrastructure is used, since as you say that's a matter for the 
> > implementations.  What we need to get straight is what the 
> > client-facing interface should look like.
> 
> 	[A few comments and questions.  I plan to update the Twiki later
> today with a list of what appear to be agreed points and 
> those still under
> debate so they can be distilled more easily from a very 
> lively exchange 
> and other comments appearing on the Twiki questions page.]
> 
> 	I would remind you of an earlier comment that we agree 
> on at least
> one transport protocol that all compliant implementations 
> support, so I 
> think there is still some room for discussion on this point.  BTW, I 
> checked the RFC for HTTP and is only says that TCP sockets 
> will 'usually'
> be used, the protocol itself doesn't preclude any other form 
> of transport
> and so your example is very relevant.
> 
> 	I haven't yet heard a call for the definition of a standard API
> but I think we need at least a straw description of one to 
> talk about the
> behavior of the interface, e.g. does a sendMessage require an ACK, is 
> there some standard "header" to a message, is there 
> negotiation between
> apps when connecting to determine compatability, is a message 
> immutable
> between transport methods or is a PLATSIC 'loadImage' message 
>  as good as 
> a D-Bus one, etc.
> 
> 	Lastly, people are still talking about the/a 'hub':  My 
> understanding is that this is an artifact of the RMI used in 
> PLASTIC, but
> some apps have embedded hubs and in other cases it's a 
> standalone process.
> PLASTIC apps all connect to the hub in a point-to-point manner (please
> correct me if I'm wrong so far).  So, is the 'hub' in 
> question a simple
> registry of apps and mini-router or does it, or the idea of 
> it, serve some
> other purpose we need to preserve?  Can a "$HOME/.ivoamsgrc" directory
> containing user preferences, a local app capability registry, 
> caches, etc
> serve the same purpose (it's a well-known location to all apps so 
> provides separation between users on the same machine, apps 
> can update 
> their capabilities db w/ each new version, scribble a file 
> saying who's
> "connected",  no real Registry lookups so it'll continue to work 
> while you're on the plane, etc)
> 
> -Mike
> 
>