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.
