In the discussions before the SAMP draft went public the idea that an MType
like 'table.load' where the format of the table was left undefined
clashed mightily
with the idea that an MType should have a well-defined, unique, meaning. I'm
actually with Alasdair that an app should be free to accept a table.load message
but reply with an error if it can't make sense of it, the idea being
that an app can
can subscribe to table.load and be expected to do something reasonable, even
if later versions would support table.load.votable.v2 as a more specific case.
For this to work, we'd need a concept in SAMP that an app subscribing to table.load.votable would be willing to read a table.load message as well, i.e. is the MType a direct string match, do we allow wildcards like table.load.*, or is there an implicit subscription to higher-level messages like table.load if we explicitly post table.load.votable as an Mtype?
I personally advocate the wildcard or super-class approach since it means we don't tie MTypes to a specific version of an app, we instead rely on an app to reject a message rather than using the Sender to find a specific match. This is more work for the Hub and an idea that didn't survive the draft writing, but I do not think the <predecessor> model of simply documenting MTypes in-use is viable in the long term and argues against the idea of flexibility.
-Mike
On Thu, May 8, 2008 at 12:52 PM, Alasdair Allan <aa-at-astro.ex.ac.uk> wrote:
>
> Mike Fitzpatrick wrote:
>
> > Do we want to define this exactly or do we need additional types such as
> spectrum.load.votable, spectrum.load.fitstable, etc? Or, do we leave it as
> just 'table' and let the apps decide whether they
> > can read the format and ignore it if they can't?
> >
>
> My answer to this question will always be... "let the apps decide". I think
> it was one of the things that made SAMP's predecessor a success. It injects
> a lot of much needed flexibility into the system.
>
> Al.
>
Received on 2008-05-09Z11:07:38