On 2/6/07, Jano <alejandro at mosteo.com> wrote: > bbackde at googlemail.com wrote: > > > On 2/5/07, Jerome Flesch <jflesch at nerim.net> > > wrote: > >> > > I don't see why this is a problem; he has to parse it when he submits > >> > > the request in the first place, and/or when he connects to the global > >> > > queue after starting up, so the code is only slightly different for > >> > > updating it. > >> > > >> > Just for the records: the difference is that in the first time we see > >> > a PersistentBlah we create a new object for it in our client list. If > >> > we see it a second time, then we have to compare our own values > >> > against the values in the second PersistentBlah and figure out IF and > >> > WHAT changed. If nothing changed then we don't have to update the gui > >> > item (which is expensive, redraw, ...). A ModifiedPersistentRequest > >> > could be applied without further checks, because something really > >> > changed. > >> > > >> I don't know how it's implemented in Frost, but in Thaw, having all > >> the value given again would not be a problem: > >> Thaw would just update all its values according to the ones given in > >> the message., and then do a refresh of the corresponding row in its > >> JTable (redraw a row in a JTable is not *so* expensive). So there is > >> no need for Thaw to compare something, and so in the end, both > >> solutions are the same for me. > >> (Yes, I know, this answer probably helps you a lot :) > > > > So Thaw does what I thought: updating all values, causing table > > resorts and redraws. I know that in most cases this isn't such > > expensive, but my point is: it is not needed at all if the node tells > > clearly what was changed. So we should not ask: _could_ the client > > handle this, but we should ask: should the client _have_ to handle > > this :) > > IMHO it's better for the node to always provide a full, consistent picture, > and leave to the client to look for what has changed (which, in the end, is > a comparison between two hash maps!). Just for the record. > > ITOH it's true that incremental updates are more efficient, but it's the > difference between forcing the client to be state-aware or not.
So you force clients to not to be state-aware? Maybe a solution is to add a new optional parameter to WatchGlobal that indicates if the client want to be state-aware (only updates from node) or not (always full information from node). > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
