Alasdair Allan wrote:
>
> Mike Fitzpatrick wrote:
>> 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?
>
> Totally disagree... ;)
>
> If an application wants to subscribe to a table.load.votable and then
> arrange a bunch of flows on receipt of this message that's fine with
> me, I think defining an action that an application must take to go
> with a specific message is the wrong way to go. What happens at the
> application end on receipt of a specific message is, as far as I'm
> concerned, up to the application.
>
> Specifying that something that's decided to accept a
> table.load.votable has to accept a table.load is a an anathema to this
> concept. If the sender wanted the app to do something (arrange a bunch
> of flowers) it should have sent it a message it was willing to accept.
>
> Al.
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. 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.
Cheers,
Isa