multiple loading of the same table

[Mark Taylor]

Ivan,

My feeling about this is that the broadcasting client is at fault.

If it sends a table.load.votable message to another client or clients,
it is telling them to load the table in question.  Yes the receiving
client could in principle track which tables it's loaded so far and 
try to avoid picking up the same one again, but I'm not in favour of
complicating the (currently very straightforward) semantics of the
MType with such rules.  Also, there might be legitimate cases when 
you want to send the same table twice (for instance, in TOPCAT you 
might have made some changes to the table as sent in the first place, 
and want to reload a fresh version).

I'm not sure exactly how your web page is designed to be used, but in 
general I'm uneasy about an automatic broadcast of a table when a web 
page is loaded.  There are several possible reasons why you might not 
want a table.load.votable broadcast when you open a web page, and the
fact that you've already done it once recently is only one of them.
In general I think it would be more appropriate to have a link or
button on such a page which allows the user to explicitly send the 
table in question to SAMP clients (even better, to choose whether 
to broacast to all or send it to a given selected client) if that's 
what they want to do.  Would this be appropriate in your case?

Mark

On Tue, 16 Mar 2010, Ivan Zolotukhin wrote:

> Hello,
> 
> I've encountered a bit frustrating behavior of SAMP clients when
> loading single table several times in a sequence. If I emit a SAMP
> message like this
> 
> samp.mtype: table.load.votable
>   samp.params: {
>      name: SAI OCL Catalog
>      table-id: MyVOTable
>      url: http://ocl.sai.msu.ru/catalog/votable/ }
> 
> multiple times, Aladin, TOPCAT and ds9 load the same table (note that
> table-id and url are static) again and again disregarding the fact
> that it is already loaded. While one may say that this behavior is
> uncommon use case of manual table broadcasting (which is probably
> true), the emerging SAMP plugins for browsers bring this problem up as
> pressing.
> 
> Imagine I want to load automatically the VOTable counterpart of the
> displayed HTML table upon web page load. If user hits reload button in
> his browser or if he simply returns back after visiting some other web
> pages, he gets multiple tables loaded in his VO clients. At the same
> time, it is likely to be incorrect to keep track of broadcasted tables
> on a side of transmitting client (browser SAMP plugin in this
> example), since e.g. one may restart this client and loose its
> previous state easily or e.g. one may restart connected TOPCAT without
> restarting connected Aladin and we won't erroneously broadcast the
> table when we really should. Adding clients polling to the protocol to
> get the list of loaded tables in my mind is not an option either.
> 
> What do you think about tracking repetitive objects loading in
> receiving clients?

--
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/