Applications Messaging Standard

[John Taylor]

I'd like to second the motion to keep the bootstrapping process to be  
kept ultra simple.  It needs to be simple enough that we can use the  
messaging system from environments such as IDL and Matlab.


On 15 Feb 2007, at 18:34, Doug Tody wrote:

> On Thu, 15 Feb 2007, Tony Linde wrote:
>> 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
>
> My impression of the Windows registry is that it is only for fairly  
> static
> configuration info, not runtime stuff.  If it had a mechanism for  
> sharing
> info which goes away after a session without updating the registry  
> store,
> it might provide a Windows-specific global sharing mechanism.
>
>
> On Thu, 15 Feb 2007, Mark Taylor wrote:
>> Well that's the thing, isn't it - in most current usage scenarios  
>> there is not something which serves this purpose.  The session  
>> mananger must
>> (a) understand the messaging protocol well enough to be able to  
>> generate connection bootstrap information (e.g. select an unused  
>> port),
>> and (b) be relied upon to be the agency which starts up any  
>> application wanting to participate in messaging conversations.
>> In practice that means it must be something that we (definers of
>> the messaging protocol) write, or influence the writing of,
>> and it must be something which all users of applications use.
>> In the era of specialist astronomical application environments
>> (IRAF cl, Starlink ICL) this was perhaps a workable idea, but such
>> things are hardly ubiquitous these days.  If the OPTICON proposals
>> (http://archive.eso.org/opticon/twiki/bin/view/Main/WebHome) get
>> off the ground that might provide such a platform, but (i) I don't
>> think it would be wise to wait until that point before having a  
>> usable messaging system and (ii) I don't think we should restrict  
>> use of any messaging system to people working within any such  
>> particular environment. In most cases, astronomers just want to  
>> click'n'go, and simply won't end up using things which require
>> rigid ways of working that they are not used to.
>
> This is good stuff Mark, and basically I agree with all this.
> We need to find a way for our desktop systems to be much more open,
> and plug-and-play (yet still be able to do more than just have a few
> stand-alone tools).
>
> I think most of the issues with trying to use file-based mechanisms
> in a distributed computing scenario can be avoided so long as we
> do not use such a file-based mechanism for the runtime, once the
> "bootstrap" has been completed.  It would be nice however to have
> a scheme that can still work in a read-only file system scenario,
> which doesn't alias multiple sessions to the same location, which
> doesn't leave dreg files behind after a crash, doesn't have race
> conditions as files are created and then written, etc.
>
> With a file-based mechanism I think there will still be platform
> issues, as Tony has mentioned.  On Windows the comparable mechanisms
> are "C:\Documents and Settings", where application data is normally
> stored (as a user I hate this as it is difficult to manage), and
> the windows registry, where configuration data is stored.  It is not
> clear the Unix-style of dot files under HOME carries over all that
> well to Windows.  BOTH platforms however (and all modern platforms
> I know of), do have comparable environment mechanisms, and networking,
> which are good runtime mechanisms for concurrent programming.
>
> The best alternative to a file-based mechanism for bootstrap might be
> a simple network-based scheme of some sort.   Both PLASTIC and XPA for
> example, already try to provide a simple runtime, socket-based naming
> or registration facility.  A possible alternative might be to use a
> portable mechanism such as the environment, with a built-in default
> address which apps could fall back on, to define a shared socket
> used to store simple keyword-value information via some trivial
> standard protocol.  Given this we could bootstrap the messaging
> system, and support unique per-session addresses and so forth (the
> per-session messaging would dynamically assign a different, unique,
> controlled-access socket).  Perhaps we should consider defining *two*
> things: such an ultra-simple, network-based keyword store, and a
> simple standard inter-tool messagaging protocol.  I suspect that the
> simple keyword-store could be as useful as as the inter-tool  
> messaging.
>
> 	- Doug
>