Applications Messaging Standard

[John Taylor]

On 8 Feb 2007, at 18:18, Doug Tody wrote:

> On Thu, 8 Feb 2007, John Taylor wrote:
>
>> On 8 Feb 2007, at 17:42, Doug Tody wrote:
>>> The point is not to "support" all the mentioned messaging  
>>> technologies,
>>> but rather to define a simple messaging protocol which is  
>>> sufficiently
>>> independent of implementation to be possible to implement on top of
>>> any sufficiently general messaging infrastructure.
>>
>> So if I understand this correctly, you want to abstract out the  
>> operations and semantics that are needed.  For instance (to take  
>> PLASTIC is an example), we have the operations
>>
>> register
>> request
>> requestAsynch
>> getRegisteredIds
>> .....
>>
>>
>> and these operations are independent of whatever wire protocol  
>> sits underneath?
>
> Exactly, yes.
>
>

K'ching.  The penny has dropped.  Right - well, I'm all for that  
then.  We still need to discuss wire protocols, but yes, we can do  
this bit separately.

On the subject of wire protocols: I get the feeling that one of the  
main objections to PLASTIC is due to its support of JavaRMI as well  
as xml-rpc.  This makes it very difficult to implement a Hub in  
anything other than Java (although makes no restrictions on the  
language of the client app).  In that case we should make it  
optional.  In fact, I'm in favour of allowing a (small) number of  
wire optional protocols subject to the following conditions:
1) messages should be "freely" convertible between the protocols  
(which I guess is another way of saying that the messaging protocol  
is independent of the wire protocol)
2) it should be possible to build a "Hub"(sorry Mike) that supports  
all the protocols.

Rule 2) is to ensure that our application-space doesn't get  
fragmented into mutually inaccessible parts.  So, people are free to  
innovate with new wire protocols, and then if they come to the Apps  
WG and can persuade everyone there's a good reason to add a new wire  
protocol it can become part of the standard.  That's not a green  
light to add any old wire protocol to the standard (SOAP anyone?).    
The standards body's role is to accept or deny requests for new wire  
protocols, and define how the conversion is done.

My view is that we should "let the market prevail".  In 6 months time  
we can see which wire protocols are popular, which "hub"  
implementations are being used.  We might decide that we need then to  
make one of more wire protocols mandatory.

Right.  That was probably controversial.  I'm going to Prague for the  
weekend before the replies from Alasdair and Mark hit.

Bye for now.

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/apps/attachments/20070208/d6d5686c/attachment.html>