Applications Messaging Standard

[John Taylor]

On 16 Feb 2007, at 22:53, Doug Tody wrote:
>
>
> On Fri, 16 Feb 2007, John Taylor wrote:
>> This does sound pretty good, though as Alasdair has pointed out it  
>> transfers
>> some of the complexity from the hub to the client.  Our philosophy  
>> with
>> PLASTIC has always been to make life easy for clients even if we  
>> make life
>> harder for hubs.  If we are going to require a client to be able  
>> to do direct
>> socket programming, then I see fewer benefits in having multiple wire
>> protocols.  Why not just pick (e.g.) XMLRPC and be done with it?   
>> Then you
>> could scan through the ports using the XMLRPC library and when you  
>> get a
>> connection just call a "getUser()" method to decide whether it's  
>> the right
>> hub.
>
> There should be a single protocol for connecting - something simple -
>
Agreed.  From a client's point of view scanning ports and using some  
socket-based protocol that we've made up is less simple than reading  
a file, though I recognise that it has other merits.

> but it is still better I think to have the option of multiple
> protocols for messaging once connected.  Otherwise we limit  
> flexibility
> (layering) and risk getting locked into one technology (didn't we
> already cover all this?!).

One of the main benefits of multiple protocols is that a client  
author gets to choose what is the easiest and best choice for him,  
and the "hub" handles any translation.  That's why we decided to do  
this with PLASTIC.
This benefit is less valuable if the initial handshake becomes more  
complicated, so I don't think it's unreasonable to weigh this against  
the benefit of clarity and simplicity you would get from only  
supporting a single protocol.


>
>> As Doug says, in most cases you'll get the right port first time
>> anyway.  In fact, one could go further an eliminate the hub and go  
>> peer to
>> peer....
>
> Both direct connections and producer/consumer are important.  It is  
> best
> to allow for both.  That is why we quote the word "hub".

Not me.  I quote it to distinguish it from the Plastic Hub.


>
>> each application picks a port in a defined range to host its own
>> xmlrpc server.  When an application wants to discover its peers it  
>> scans this
>> range, and should easily detect whether the port belongs to a  
>> suitable
>> application.  If the application is going to have to scan a list  
>> of ports
>> already, I don't see that this is much of an extra burden in  
>> return for
>> removing the need for a hub.
>
> You have lost me here.  What is a "peer" in this case?

An application that wants to send or receive a message.  As distinct  
from the "hub" process that routes them.

> I think you
> just have one session and everything connects to it.  It is still
> good to have apps connect directly to the messaging system, whatever
> it happens to be, and let the messaging infrasructure worry about
> how to make apps talk to each other.  Lets not rule out the future use
> of real messaging infrastructure by assuming that there is none and
> everything is just a direct peer-to-peer socket connection.

You could turn out to be right - in fact a while back a group of us  
came to the conclusion that we'd still like a hub-based architecture  
even if there was only a single wire protocol.  Nevertheless, again,  
it's not unreasonable to weigh the benefits of having a hub for  
client authors versus the extra complication for users (and the  
difficulties hitherto discussed concerning embedded hubs etc).


>
>> My only unease about it is my use case of wanting to use the  
>> messaging system
>> from very simple environments such as IDL.
>
> I think this is way overstated - I see people doing all kinds of  
> complex
> things such as SOAP with IDL (or IRAF, whatever).  If nothing else,  
> with
> a C-based environment, all you do is write a messaging plug-in.

SOAP from IDL?  I'm impressed.  You couldn't point me to an XML-RPC  
library for IDL could you?  We've been looking for one for ages.

More seriously, if we chose a messaging system that wasn't easily  
accessible from IDL, yes, we could write a plugin, or even a  
standalone application that translated the IVOA messaging system to  
something more easily accessible.   But, if these requirements could  
be considered from the outset that would be nice.

J




>
> 	- Doug
>