new MType proposals.

[Mark Taylor]

On Tue, 31 Mar 2009, Noel Winstanley wrote:

> Hi,
> I'd like to propose 2 new SAMP mtypes, for exchanging references to registry
> resources and academic papers. Both are based on existing plastic messages at
> http://eurovotech.org/twiki/bin/view/VOTech/PlasticMessagesProposal
> 
> -------
> 
> 1 Exchange a bibcode (http://en.wikipedia.org/wiki/Bibcode)
> MType:
> 	bibcode.load
> Parameters:
> 	bibcode: (required) the bibcode to load
> Return Values:
> 	none

this looks fine to me.

> --------
> 
> 2 Exchange a set of VOResources
> (http://www.ivoa.net/Documents/latest/VOResource.html)
> MType:
> 	voresource.loadlist
> Parameters:
> 	name: (optional) name for this set of resources
> 	ids: (required) map of IVOID -> (optional) URL
> 		The keys of this map are the IVO-identifiers of the
> voresources to load. The optional value associated with each key is an URL
> from which the XML of the voresource can be downloaded.
> 
> Return Values:
> 	none
> 
> The URL values in the ids map are optional and need not be provided, but may
> be useful for a receiving application which isn't able to query a registry
> service. (e.g. because it doesn't bundle the whole SOAP stack required to do
> this)

I wonder whether this ought to be decomposed into two MTypes,
one in which the URLs are present and one in which they are not.
The reason is that an application which can't do IVOID->resource-info
mapping (e.g. no SOAP, no registry access) probably won't be able
to do much with a list of IVOIDs (will it?).  So such a client would 
want to subscribe to receive messages that come with the URLs but not 
ones that don't.  An application which can do IVOID->resource-info 
mapping would be able to use either form.  An alternative would be 
to have only one MType as above, but make the URLs mandatory.

I'm not much involved with applications which send or receive this
kind of message, so I may have misconceptions about how it would be
used; more weight is due to the opinions of those (like Noel) who are
likely to use it.

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/