Applications Messaging Standard

John Taylor jontayler at gmail.com
Fri Feb 16 02:22:39 PST 2007


Hi Tony,
I believe we are just trying to discover where the hub is and how to  
invoke it.  For instance, if a hub supported xmlrpc as a wire  
protocol then it would need to get the URL of its xmlrpc server to  
the clients, perhaps by writing this URL into a file in a well-known  
location.  Thereafter, all the discovery of other applications and  
their capabilities takes place by talking to the hub on this URL.

John


On 16 Feb 2007, at 09:25, Tony Linde wrote:

>> is to explore alternatives to the use of file-based mechanisms for
>> simple runtime discovery in a LAN type environment.
>
> Can I ask if we all are talking about the same thing here? What are we
> trying to discover at runtime with this file-based mechanism?
>
> Where the hub is and how to invoke it?
> How to communicate with the hub?
> What other plastic apps are running and what they can do?
>
> As I understand it, only the first two need a file-based mechanism  
> since the
> third is only done after the hub is up and is carried out via a  
> message to
> the hub. Is this right?
>
> And why a LAN type environment? I thought we were only looking at  
> single
> client / single user use for now?
>
> T.
>
>> -----Original Message-----
>> From: owner-apps at eso.org [mailto:owner-apps at eso.org] On
>> Behalf Of Doug Tody
>> Sent: 15 February 2007 22:21
>> To: John Taylor
>> Cc: apps at ivoa.net
>> Subject: Re: Applications Messaging Standard
>>
>> On Thu, 15 Feb 2007, John Taylor wrote:
>>
>>>> IP (sockets) on the other hand, were designed for this purpose.
>>>> A simple solution is to provide a well-known port for discovery
>>>> (basically just a simple keyword-value cache; back it up with an
>>>> environment variable or whatever to config the address)),
>> and hand-off
>>>> to dynamically allocated ports for session stuff.  This
>> can all be done
>>>> at the protocol level without an API, is universally
>> available, and is
>>>> really not much more complex than using a file.  Probably
>> less complex,
>>>> when you consider the subtle issues that files have for
>> this purpose.
>>>
>>> I'd be interested to know how much easier or harder it
>> would be to use IP
>>> from relatively primitive programming environments such as
>> IDL (that's not a
>>> slur on IDL...it's very sophisticated in other ways).
>>
>> Well, we are after all talking about messaging software right?  Any
>> system/app/language using this will already have had to figure out  
>> how
>> to talk to a socket.
>>
>>> One question I have is
>>> what would happen on a multiuser machine?  Would you need
>> some system process
>>> running on the one shared well-known port?
>>
>> Not necessarily, but you could.  The same mechanism could be set up
>> either way.  In either case the idea is one would use this only to
>> provide a simple discovery mechanism, to bootstrap things up, then
>> hand off to other facilities.  Having something which at the most
>> basic level can be accessed by multiple accounts could be a useful
>> thing it itself, as sometimes resources which need to discover each
>> other and communicate are running under separate accounts.
>>
>> Clearly there are issues which need further thought, but the point
>> is to explore alternatives to the use of file-based mechanisms for
>> simple runtime discovery in a LAN type environment.
>>
>>  	- Doug
>>
>
> http://www.Taglocity.com Tags: IVOA, apps
>



More information about the apps mailing list