URL handling in SAMP message parameters
m.b.taylor at bristol.ac.uk
Fri Oct 7 06:46:01 PDT 2011
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
> - '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
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 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/
More information about the apps-samp