Applications Messaging Standard

[John Taylor]

Hi Tony,
Although we use this area in PLASTIC, it's only for holding a small  
config file so there's not much chance of our causing the problem you  
describe.
John


On 9 Feb 2007, at 17:52, Tony Linde wrote:

>> ...  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
>>
>>
>