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 :) > > > At the end this would allow to handle each PersistentBlah as > > > introduction for new items. > > > > > > But this was just for the records, we need a decision. Because I can't > > > add further details to my point of view to convince you I tend to > > > implement what you proposed, because its 'your' code :) > > > > Input from other client authors would be useful. Jflesh? > > > Jfles*c*h :) > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
