Apps Messaging -- A New Approach

[Gretchen Greene]

	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