multiple loading of the same table

[Ivan Zolotukhin]

Mark,

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

I'm not saying we should change MType semantics. The only reasonable
thing that can be changed in this case is either transmitting or
receiving clients behavior, so seems we should focus on that.

> 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).

Can you add more cases here? What you're saying now only means to me
that current TOPCAT behavior is not perfect and needs to be improved.
When one changed the table in TOPCAT, it is not the previous table
anymore and its table-id most likely should be changed. Then, there's
discarding mechanism in TOPCAT, so that one can discard the table and
load it again if one needs to reload the table correctly, otherwise
there's a strong possibility of a confusion because tables do look
similar.

Moreover, there's a bunch of SAMP clients (ds9, Aladin) that do not
allow table change AFAIK; and they now endlessly load identical tables
disregarding their table-ids. This looks like 'no primary key'
anti-pattern actually, because no one knows how to e.g. reference that
exact table user has loaded first. And the only principal way to
change this is to maintain some sort of a PK check at the receiving
client level, otherwise there definitely will appear some other sorts
of mess in future.

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

My idea is that when one loads a web-page, the HTML table rows are
started to be highlighted (sending corresponding message to SAMP
clients) on mouse over without unnecessary clicks. Since I want it to
be done automatically (because I try to target the application to the
non-VO audience which is not familiar with all this logic "click to
load this table in external tools otherwise there's no fun here";
everything should be as simple as possible), for me it means that you
propose something like a modal window asking user "go and check if you
loaded that before", which is not appropriate, because this simple
check can be done by computer and there's no need to bother (novice)
user with it.

If I only had a single chance to track reliably tables that were sent
by a transmitting client, I wouldn't raise this discussion here. But
on broadcasting client there are only compromise variants that do not
solve the real problem, because the problem depends only on receiving
client state which is principally unknown at transmitting client.

Generally speaking, I'm saying the only essential thing: tables with
*equal table-id* should not appear multiple times in any receiving
client because there's no sense in it and even more, it's evil,
because table-id term must mean something unique across the
collection.

--
Regards,
 Ivan


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