Apps Messaging -- A New Approach

[John Taylor]

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: owner-apps at eso.org [mailto:owner-apps at eso.org] On Behalf Of Mike
> Fitzpatrick
> Sent: Thursday, April 19, 2007 2:43 AM
> To: apps at ivoa.net
> 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
>
>
>