SAMP RFC changes

[Mark Taylor]

On Tue, 20 Jan 2009, Juan de Dios Santander Vela wrote:

> El 20/01/2009, a las 13:26, Mark Taylor escribió:
>
>> Bob,
>> 
>> I have now addressed your comments from the SAMP RFC.
>> I have added responses on the wiki page
>>
>>  http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/SampRfcDiscussionV11
>> 
>> and have made corresponding edits to the SAMP document which you can
>> see in the Volute repository:
>>
>>  http://code.google.com/p/volute/source/diff?spec=svn934&r=933&format=side&path=/trunk/projects/samp/doc/samp.tex&old_path=/trunk/projects/samp/doc/samp.tex&old=923
>> 
>> If there is anything you're still unhappy with, please say. Thanks again 
>> for your input.
>
>
> I just came today with a doubt that I think it could be clarified in the 
> specification: what if a developer wants to augment an existing application 
> domain MType with an additional, obviously optional parameter? This seems to 
> be encouraged by the extensibility hooks everywhere in SAMP (free MTypes, 
> named parameters tagged with data types).
>
> In particular, I was thinking of adding a session-id parameter to 
> image.load.fits and table.load.votable, so that applications using that 
> session-id can use it to trace related data loads, but those not knowing 
> about it will happily discard it, and the MType semantics have not been 
> changed.
>
> But this brings a problem: even if a MType parameter is optional, should all 
> applications heed it? For instance, a script with no GUI might choose to 
> ignore the table-id or name parameters
> of a table.load.votable message. Should we state that optional parameters may 
> have no side-effects on receiving applications if they so choose, or that an 
> MType message functionality should not be fundamentally changed by the lack 
> of optional parameters with no default values?

Hi Juan,

yes, like you say, this kind of extensibility is explicitly encouraged
in MType parameter sets and at other places within SAMP.
Section 5.2 says:

    "The parameters and return values associated with each MType form
     extensible vocabularies as explained in Section 2.6, except that
     there is no reserved "samp." namespace."

and Section 2.6 contains the text:

    "The general rule is that hubs and clients which encounter keys
     which they do not understand should ignore them, propagating them to
     downstream consumers if appropriate. As far as possible, where new keys
     are introduced they should be such that applications which ignore them
     will continue to behave in a sensible way."

which I think answers your query - do you agree?

I admit that this clarification is easy to miss (it took me a few minutes
grepping the LaTeX to find it, and I knew it was there...).  I think that
may be unavoidable given the length of the document and what it's trying
to cover, but if you've got a suggestion for how it could be made more
obvious, fire away.

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/