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.

-- MarkTaylor - 22 May 2008