> I understand your point of view but I would like to propose some scenarios
> where this could lead to some problem.
> For example, if VOSpec has to subscribe to both file.load and
> spectrum.load.image, this means that if Aladin broadcasts fits images with
> file.load, VOSpec has to understand that they are not spectra.
Right, but this may legitimately happen anyway. For example, your intent may
be that file.load is used to load an ascii spectral line list and
spectrum.load.image
to load data. In a configuration where another app broadcasts a
file.load you'll still
see the message and will have to check that it isn't the linelist you
can handle and
reject the message (or reply with an error). Most likely another app would send
you a directed message for the linelist file.load, but you'd still
need to handle the
broadcast case.
The alternative is that we decompose file.load to all possible uses, e.g. a spectrum.load.linelist, a image.load.filenameList, a file.photometry.transformations,.....
> Maybe there is a tricky way to manage all the possible formats and
> everything, but I think the protocol should avoid as much as possible such a
> messy thing. As a SAMP client, I would like to subscribe just to the
> spectrum MTypes in principle, because my application manages just spectra,
> but yes I see this has to be discussed because we don't want to make the
> protocol too much complicate.
Specifying the mtypes to the lowest level of detail is too burdensome
and doesn't
allow much flexibility. For example, I might want to subscribe to
table.load with the
idea I'd see table.load.votable (see earlier where it isn't decided
this is how things would
work). Maybe my app doesn't directly understand VOTable, but there's
a service that
does table.convert I can call to get back a FITS file I can understand
and so still
satisfy the table.load.votable message in my own way. If the service
weren't online,
I might just ignore the message.
-Mike Received on 2008-05-14Z11:28:00