InterOpMay2008SampSummary < IVOA

IVOA Web>IvoaApplications>InterOpMay2008Applications>InterOpMay2008SampSummary (2008-05-22, MarkTaylor) (raw view)









<br/>
<!--
      * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup
-->

---+ Report of SAMP sessions at Trieste 2008 Interop

---++ SAMP status

   * The existing SAMP draft document was described.
   * A demo was given showing *three* interoperating components
      * A Perl hub (Alasdair Allan)
      * Aladin (Thomas Boch)
      * A Python command-line client (Thomas Boch)

---++ ISSUEs resolved

The ISSUEs named in the list below correspond to the headings of the presentation, and in some cases to Subject lines of threads on the =apps-samp= mailing list.

   $ ISSUE Synchronous call timeout?: Add a =timeout= parameter to the =callAndWait()= hub method
   $ ISSUE Rename setMetadata: Rename =setMetadata()= to =declareMetadata()=
   $ ISSUE getHubID/getSelfID: Hub and self IDs will be returned in a map from the =register()= method; hub =getHubId()= method will be removed
   $ ISSUE MType Wildcarding: Simple wildcarding will be permitted for MType subscriptions.  Wildcarding matches entire sub-trees: =a.b.*= matches =a.b.c= and =a.b.c.d= etc. 
   $ ISSUE Rationalise Reserved Words: All controlled vocabularies (metadata keys, message content encoding keys, lockfile keys etc etc) will use the =samp.= prefix for reserved values, and values not so prefixed may be used with meanings undefined by SAMP.  A section should be added to the document clarifying this policy, rather than restating it for each case.
   $ ISSUE Annotations: API will be modified so that Annotations (and possibly other things) could in principle be declared along with the MTypes themselves at subscription time.  The =setMTypes(list mtypes)= method will be replaced by =declareSubscriptions(map subscriptions)=, where =subscriptions= is a map with MTypes for keys, and a map for a value.  No keys are currently defined for this map (i.e. it is likely to be empty)
   $ ISSUE Response Encoding: =success= flag will be removed from =reply()= (etc) methods, and =response= object will contain all success/failure information. Instead of a binary success flag, a =status= value (under the =status= key in the response map) will be used; this will have the defined keys =ok=, =warning=, =error=.  The =error= key SHOULD be present only if =status= is not equal to =ok=.
   $ ISSUE Message Send Terminology: Options 1 or 2 chosen --- leave the text substantially as it is, but add some clarifications in the document introduction to prevent confusion arising between the ideas of Delivery Pattern and MType Category.  Discussions of MType Category outside of the MType descriptions should be removed or carefully flagged to avoid confusion.
   $ ISSUE HTTP/JSON: No additional HTTP-GET-based access mode will be added to the existing Standard Profile
   $ ISSUE Rename Standard Profile PLASTIC: The group was in favour (nem. con.) of retaining the PLASTIC name alongside the SAMP name in some form --- exactly how TBD.

---++ MType Vocabulary

A number of issues were raised concerning the way that MTypes should be defined and organised.
   * Assembling the actual vocabularies will happen on the =apps-samp= mailing list in the coming weeks and months.
   * "Administration" type messages should be formally defined and written into the SAMP document itself.  Others (application-type messages) can be arrived at more informally and published outside the document --- maybe in an IVOA Note.
   * The priority for which (sets of) messages will be defined first will be somewhat determined by which ones application developers need in order to use SAMP in their applications.

---++ PLASTIC/SAMP Migration

   * All developers present said that they expected to move their applications from PLASTIC to SAMP in the forseeable future. 
   * Most seemed happy to provide SAMP and PLASTIC functionality alongside each other in a single application for a transitional period so that existing application interoperability does not become (temporarily or permanently) broken from a user's point of view, although some degradation may be inevitable.
   * Some infrastructure authors also said that they intended to provide PLASTIC/SAMP bridge components which would allow PLASTIC-only applications to talk to SAMP-only ones to some extent.
   * A suitable set of SAMP MTypes matching the existing PLASTIC messages which are in use will be necessary for these strategies to work.


---++ Next Steps

   * Mark Taylor will produce a draft of the document in the next couple of weeks following the meeting and circulate it for (prompt!) comments on the =apps-samp= list.
   * This _will_ be submitted for publication as an IVOA Working Draft before the end of June.
   * Application authors will incorporate use of SAMP over the coming months.
   * Depending on this experience, changes to the draft may be proposed, discussed and accepted.
   * A move to Proposed Recommendation will be made when the draft looks stable and working.  We do not anticipate a problem in getting the two interoperable implementations formally required for that stage --- the Apps group has been pretty good in coming up with implementations.

-- IVOA.MarkTaylor - 22 May 2008
Topic revision: r1 - 2008-05-22 - MarkTaylor
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema