multiple loading of the same table

[Mike Fitzpatrick]

On Tue, Mar 23, 2010 at 9:29 AM, Mark Taylor <m.b.taylor at bristol.ac.uk> wrote:

> Again, happy to hear opinions of third parties about this.

Since you asked.... WRT to SAMP itself I don't see a problem and my main
theme is, 'don't shoot the messenger'.  I thought there was language in the
spec that says an app is free to ignore or implement a mtype as it pleases
but can't find it just now, otherwise I thought this was generally understood.

    An mtype of 'table.load.votable' means just that, load the table.  Whether
the sender should have known it already sent the table, or the receiver should
match the table-id and ignore the message is irrelevant to the meaning of the
message itself.  Receivers are free to ignore the message, raise the window
showing the table, create a new window with a new table, or refresh an existing
window.  In any case, the sender shouldn't know/care how the message
functionality
is implemented by the receiver.

   OTOH, if the *behavior* that a sender wants is something like a "refresh the
table" then send a 'table.update.votable' mtype instead.  It has a
clearly different
meaning that e.g. might imply the content of a given table-id has changed and
the desired behavior is a refresh in the receiving app.  This thread seems to
assume that table.load.<foo> mtypes are all that we have available, the spec
clearly states we can create new ones as needed.

    An app that is an infinite loop sending table.load.votable messages is
perfectly valid wrt to the SAMP spec, although clearly pointless (but
'pointless'
has never been a hinderance to astronomy apps thus far 8-))  An 'mtype' is
meant to mean one thing only, regardless of how 'load' is commonly implemented
in other apps.  If you want a different interoperability behavior,
send a different
message.

FWIW,
-Mike