> 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? > I'm not sure why, but it doesn't sound to me like a good idea to put 10.000 transfers on the global queue ? By the way, a PersistantPutDir is not managed as only one transfer ? (I must admit I don't know, I never try them)
> 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 > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
