Am Dienstag, 6. Februar 2007 09:06 schrieb Jano: > 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.
for a full, consistent picture of the queue the client need to do a "ListPersistentRequest". all others (the persitant command sending connection and all watchers) should get notyfied with a small notify message instead of sending the priority changed PersistantPutDir (~10k, 2000 items in repository) from freenetsvn to each queue watcher. while rebuilding a freenstsvn-repository i have up to 5 PutDirs in queue. so thaw needs to parse 10,000 lines to find 5 changed "Priority=newvalue" items? imho, bback's proposal for the notifier should appeare on the todo list. > 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. > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Mfg saces
