URL handling in SAMP message parameters

[Mark Taylor]

On Fri, 7 Oct 2011, Laurent Bourgès wrote:

> Dear Samp users,
> 
> In several standard MTypes, arguments can be url (string) giving the
> URL of the document to load :
> - table.load.votable
> - table.load.fits
> - table.highlight.row
> - table.select.rowList
> - image.load.fits
> - spectrum.load.ssa-generic
> - voresource.loadlist
> 
> Although SAMP is dedicated to desktop interoperability, such URL can
> use any protocol (file://, http://, ftp://).
> To be concrete, I am currently using JSAMP 1.3 and I must handle both
> 'file://' and 'http://' URL when I process one table.load.votable
> message:
> - 'file://' are provided by our JMMC applications: data are stored
> into local files before sending their URL via SAMP
> - 'http://' are provided by topcat because it embeds its own HTTP server

To address this particular question of Laurent's:

> - Is it possible to describe which URL procotols must be supported by
> SAMP clients (file, http at least) ? I do not want to support other
> protocols (ftp ...) : the specification / MType wiki page should give
> explanations / details

Since this is a semantic issue it's really in the realm of MTypes,
but since it is a common consideration for many MTypes in use,
I think it's reasonable to discuss it in the standard itself.

I'm reluctant to be too prescriptive (e.g. a MANDATORY list of
what senders are permitted to send or recipients are required to
understand); for one thing, it will probably be ignored - we can't
stop people using weird URL protocols here, and if cooperation between
sender and recipients means they work then we shouldn't do -
and for another thing, the list of what are 'common' protocols may
change over time.

Section 3.3 of the standard (SAMP Data Types) already contains the
following text:

   Although SAMP imposes no maximum on the length of a string, particular
   transport protocols or implementation considerations may effectively
   do so; in general, hub and client implementations are not expected
   to deal with data items of unlimited size. General purpose MTypes
   SHOULD therefore be specified so that bulk data is not sent within the
   message. In general it is preferred to define a message parameter as
   the URL or filename of a potentially large file rather than as the
   inline text of the file itself.

I suggest adding the following:

   SAMP defines no formal list of which URL schemes are permitted
   in such cases, but clients which need to dereference such URLs 
   SHOULD be capable of dealing with at least the ``http'' and ``file''
   schemes.  ``https'', ``ftp'' and perhaps other schemes may also
   be encountered, though clients are discouraged from sending them
   unless there is some good reason to do so.

Laurent, do you think this is OK?  Anyone else have any comments?

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/