[Plastic-devs] Fwd: Apps Messaging -- A New Approach

[John T. <jon...@gm...>]

Hi all,
Just in case you're not on the applications IVOA list, we're looking  
at some changes we'd like to make to PLASTIC as it forms the basis  
for a new IVOA standard, provisionally entitled SAMP (Simple  
Application Messaging Protocol).  I've summarized the changes here:

http://www.ivoa.net/twiki/bin/view/IVOA/PlasticOnePointOh

Please do review them (there's only about 10 of them), and vote on  
them, especially if you're developing against PLASTIC.

Let me know if you need clarification of any of the changes.  The  
main thing is that I'm reasonably confident that we can make them  
without breaking your applications - we can run both the old and the  
new protocols in parallel (at least for a while).

John

Begin forwarded message:

> From: John Taylor <jon...@gm...>
> Date: 25 April 2007 16:31:14 BDT
> To: "Gretchen Greene" <gr...@st...>
> Cc: "'Mike Fitzpatrick'" <fi...@tu...>, <ap...@iv...>
> Subject: Re: Apps Messaging -- A New Approach
>
> Hi Mike & Gretchen,
> Apologies for not responding to this sooner.  Mike: I think your  
> approach offers a good way forward, and like Gretchen I favour an  
> emphasis on making this available pretty quickly so we can get  
> feedback for any future mods or more general system.
>
> I believe Mark's timetable:
> http://www.ivoa.net/forum/apps/0701/0156.htm
> is achievable if we keep focussed on the simple stuff.
>
> Over the last year a number of changes have been suggested for  
> PLASTIC, and the discussions on this list have thrown up a few  
> more.  Rising to Mike's challenge, I've collected them on this wiki  
> page:
>
> http://www.ivoa.net/twiki/bin/view/IVOA/PlasticOnePointOh
>
> All of these changes can be made while retaining backwards  
> compatibility with current PLASTIC apps, at least in the short  
> term.  If I've missed something important, please let me know.    
> Some  of the changes are lacking a sponsor: if you want to adopt  
> one then go ahead, or I'll delete it if it gets no support.  I've  
> taken the liberty of attributing some of the changes to Mark and  
> Mike - feel free to remove your name if I've got it wrong.
>
> So, cast your votes for the changes you want to see, and those you  
> don't.  Please do take part - it's important we get your views,  
> *particularly* from people who intend to develop applications  
> against this protocol.
>
> Once we've got a list of changes to focus on, we can thrash out the  
> details.
>
> John
>
>
> On 19 Apr 2007, at 20:16, Gretchen Greene wrote:
>
>> 	This sounds like a great idea to use PLASTIC with the identified
>> modifications as a first specification.  It is really important to  
>> have
>> something available for folks to prototype and work implementation  
>> to in
>> order to provide input to an extended messenging package.
>>
>> Thanks!  -Gretchen
>>
>> -----Original Message-----
>> From: own...@es... [mailto:own...@es...] On Behalf Of  
>> Mike
>> Fitzpatrick
>> Sent: Thursday, April 19, 2007 2:43 AM
>> To: ap...@iv...
>> Subject: Apps Messaging -- A New Approach
>>
>>
>>
>>
>> 	We seem to have reached a stalemate, or at least an unproductive
>> state, in the discussions and so it may be time to try a different  
>> approach.
>>
>> 	My sense is that we would all be happy with an intial version of the
>> spec that at least retains (and ideally improves) the current PLASTIC
>> capability for current high-level tools to interoperate, but also  
>> recognizes
>> that there are valid use cases that might not be handled in the first
>> version and will be fixed later (perhaps involving significant  
>> changes).
>> We've so far been working at this from the perspective of writing  
>> a spec
>> from scratch with the idea of incorporating PLASTIC abilities into  
>> the new
>> framework;  what I'd like to suggest is that we explore the  
>> "cleaned-up
>> Plastic" angle to see if we can make more headway by trying
>> to turn PLASTIC into a v1.0 spec we can all live with.	Note what I'm
>> suggesting is still more than just a PLASTIC v1.1, but we use a  
>> different
>> starting point in the discussion (and put the burden on the  
>> PLASTIC folks to
>> propose a roadmap that everyone else can buy into instead of  
>> asking them to
>> buy into a new idea).
>>
>> 	John had earlier posted (in the 'Apps Messaging - Twin track?'
>> thread) his list of proposed changes but there were no replies to  
>> indicate
>> how much opposition these would meet.  These included some of the  
>> concepts
>> we've already discussed such as a basic message content model  
>> through use of
>> 'mtypes' rather than ivorns and asynchronous delivery -- do the  
>> PLASTIC
>> developers see these things as fundamental obstacles to reaching some
>> agreement?
>>
>> 	In the interest of neutrality, my own distaste for the 'VOOM' name
>> (sorry Rob), and borrowing from the wisdom of others, let's call
>> this the Simple Application Messaging Protocol (SAMP).	It may in fact
>> be a reworked PLASTIC but the 'Simple' part of the name may help  
>> keep us
>> focused and remind us that a more complete protocol will follow.  
>> Keeping in
>> mind our earlier limits that this be a single user/desktop system,
>> separating message from transport etc, and recognizing that known
>> limitations will need to be formally addressed as we move through  
>> the stds
>> process anyway, I'd like to continue this thread by expanding and  
>> discussing
>> John's list of changes from the PLASTIC perspective.
>>
>> 	To start, I'll ask whether we can reach some form of basic agreement
>> about what's already been discussed, namely:
>>
>>     - Does the use of UCD-like 'mtype' offer enough of a basic  
>> content
>>       model that it can be expanded later?  The mappings to  
>> plastic ivorns
>>       are trivial and I think can be used in the current plastic apps
>> easily,
>>       their use in "advertising capability" and matching apps  
>> doesn't need
>>       to be part of the first spec.
>>     - Have we specified all the needed message attributes?  Too  
>> many? Not
>>       enough?  Is this needed at all?
>>     - I think it was Pat Dowler that came up with a Hub connection  
>> scheme
>>       that seemed agreeable, is that still true if we're modifying  
>> the
>>       PLASTIC hub?
>>     - Can we agree on the workings of a broadcast vs directed  
>> message?
>>
>> 	This isn't quite the twin track approach John mentioned, but
>> perhaps we can get the Beijing with something real to discuss.	 
>> Those of
>> us interested in the generalities will be looking for the stubs in  
>> the spec
>> we can use for later development, and I'm sure will be no less  
>> vocal in
>> pointing out the important ones seen as missing.
>>
>> 	So, let the fun begin.....
>>
>> -Mike
>>
>>
>>
>