multiple loading of the same table

[Petr Kubánek]

Hi,

SAMP is HTTP based. Using HTTP headers for cache control should be
enough in such cases and should resolve reloading. Reinventing the
wheel might be favourite pastime hobby for astronomers, but when the
technology is available, it does not bring too much benefits..

Petr Kubánek
IPL UV Valencia & IAA CSIC Granada
http://rts2.org (SAMP access planned..)

Mark Taylor píše v Pá 19. 03. 2010 v 18:24 +0000: 
> Ivan,
> 
> On Fri, 19 Mar 2010, Ivan Zolotukhin wrote:
> 
> > > 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.
> 
> Existing semantics, is that 'table.load.votable' requests a client to 
> load a table.  You're saying you want the client to load the table, only
> if it hasn't loaded it before; I think that's changing the semantics.
> Most existing tools (word processors, spreadsheets, acroread, etc), 
> when you ask them to load a file, load it, even if you just did the 
> same thing a minute ago.
> 
> > > 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.
> 
> It is definitely desirable for the identifier to be preserved over
> table modifications in TOPCAT.  The prime use that TOPCAT (and other
> tools?) currently make of the table-id, and IIRC the reason for 
> its introduction,  is so that rows identified in one tool can be 
> correspondingly identified in another.  Consider this case:
> 
>    - Aladin transmits a table to TOPCAT
>    - TOPCAT user adds columns (e.g. galactic coords) to table
>    - Aladin identifies rows and tries to transmit those to TOPCAT
> 
> Even though the table has changed within TOPCAT, there is still
> a correspondance from the rows of the original to the rows of the
> modified table, so you want rows to be highlighted.  Other kinds 
> of row-correspondance modifications are possible too (row reordering, 
> row subset application, bad value substitution, ...)
> 
> >                                                            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.
> 
> You might want to keep both copies.
>  
> > 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.
> 
> I agree that that is a  more common case for tools.  However, even 
> in e.g. Aladin, if you load an image or table from the 'File' menu, 
> and then do it again, you get two copies of the item in the tool.
> You're suggesting that load-via-SAMP has more complicated functionality
> than load-from-menu.
> 
> > > 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.
> 
> Technical feasibility apart, in my opinion it would actually be less
> confusing to have a button which says "transmit this table to TOPCAT"
> (or whatever).  If the broadcast happens automatically, the user may 
> not even suspect that the table has been transferred, or it may 
> disturb the state of an existing tool (e.g. adding points to a sky
> plot for which it's not relevant or wanted) or it may transfer the 
> table to a tool for which it's quite inappropriate (e.g. one only 
> expecting SSA query outputs) or whatever.
> 
> > 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.
> 
> I prefer predictability to cleverness, and it's not clear to me that
> your suggested behaviour is always going to achieve "what the user wants", 
> so I disagree.  But I'd be interested to hear other people's views.
> 
> Mark