SAMP Web Profile

[Mark Taylor]

Hi all,

for those of you not in Nara: in the Apps session today I made a
presentation, based on work done by myself and Jonathan Fay, and
funded by Microsoft Research, proposing a new SAMP profile
(alternative to the Standard Profile) for use by web-based clients.
You can find the presentation here:

   http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/InterOpDec2010Applications

and an associated web page with some additional explanation, demos,
and a draft of the detailed documentation here:

   http://www.star.bristol.ac.uk/~mbt/websamp/

A show of hands during the session indicated that those of the
SAMP community present at the meeting were keen to see it taken
forward, and moved towards becoming an IVOA standard.
Time was relatively short during the session, so we weren't able
to pursue much in the way of discussion of open issues.

For those of you who are in Nara, if anyone would like to take the
opportunity of colocation to discuss any such issues face to face
I'd be happy to do so.  My guess is that people won't have had
time to look at the details enough to make a break-out meeting
worthwhile, but if anybody disagrees get in touch and we could
maybe do that.  Obviously grab me in coffee breaks etc if you
want to during this week, otherwise air thoughts on this list.

Issues that occur to me that might benefit from more discussion are:

  - Security issues (already mentioned by Ray and Bob)
  - Other possibilities for cross-domain workarounds?
  - Details of the hub external URL proxying mechanism
  - Hub API details
  - Choice of port number
  - Plan for how to take the proposal forward

and no doubt some things I haven't thought of.

Regarding the last point, my ideas about where to go from here are 
roughly these:

 - I will make a public release of JSAMP including implementation of
   a hub and client conforming to the (intial draft of the) Web Profile.
   The hub will be potentially dual profile (Web Profile + Standard
   Profile), but with the Web Profile functionality deactivated by
   default.  In this way most users of the new release won't see the
   new (unstable, possibly insecure) functionality, but developers
   can play with it (e.g. write clients) if they know what they are doing.

 - I will think about tidying up and releasing the JavaScript client
   library that underpins the Web Profile demos on the web page.
   This library works, but is not well written, so needs some
   reworking or rewriting.  I'm not sure yet if I have time to do
   this in the near future.

 - Others (volunteers anyone?) could provide client-side implementations
   in various browser-based languages (JavaScript, either based on my
   JavaScript library or not; Flash; Silverlight; maybe somebody else
   could try to get an unsigned java applet or unsigned JNLP client
   working, which I've tried but can't make work for reasons I don't
   understand).  Thomas has already started!
   It would be very good if we could have another hub implementation,
   which most likely means Luigi - he's said that he's willing to
   implement Web Profile support in SAMPy, but I don't know what
   timescale is feasible for this.
   I encourage sharing of successes and failures on the apps-samp
   mailing list.  Experience using different browser configurations
   will be useful too.

 - With the implmentation experience gained from these activities,
   we can revise and improve as appropriate the draft specification
   that I've drafted.

 - Given that, we work towards the Web Profile becoming defined in a
   new section of the SAMP document, to form SAMP v1.3.  Alternatively
   we could consider it as a separate document referenced from SAMP.
   Again, the timescale for this remains to be seen, but I'd hope
   we can make some progress in the first half of next year.

Mark

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/