Am Dienstag, 6. Februar 2007 12:18 schrieb Jerome Flesch: > > 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)
the PersistentPutDir messege contains the file list, they are huge here. so for five PersistentPutDir messages i have to parse 10000 lines to find 5 changed "Priority=newvalue". and the node transfers these things whoes nobody asked for. start with a "ListPersistentRequests", this gives you a complete list, then do a "WatchGlobal" and you get only small notify messages instead the complete PersistentPutDir with 2000 files, each file have at least to items, File.x.Name and Files.x.UploadFrom i hav changed the priority, not the file list. imho, bback's proposal for the notifier should be perfectionized and implemented soon. > > 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 > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl -- Mfg saces
