> On 2/6/07, Jerome Flesch <jflesch at nerim.net> wrote:
> > 2007/2/6, bo-le at web.de <bo-le at web.de>:
> > > 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.
> > >
> > You didn't answer to the main point of my remark: Why would you put
> > 10.000 transfers on the *global* queue ?
> >
> > And, at the moment, Thaw doesn't know how to manage PersistentPutDir,
> > so it will simply drop the message, and so there is still no problem
> > on my side. and even when it will, it will probably only display one
> > row for the whole PersistentPutDir.
> >
> > Anyway, starting 2.000 transfers sounds to me quite insane (is the
> > node even able to handle all these transfers ?). Are you sure that you
> > have no design problem ?
> >
> > Imho, I think the solution of Toad has one advantage: I will probably
> > keep the implementation on the node side simpler. The simpler it will
> > be, the less bug there will be (but I'm not a node dev, so I may be
> > wrong).
>
> Don't worry to much about the node code, the one solution is as simple
> as the other one (I will implement it). This should not be the base
> for the decision, only the simplicity of the protocol!
>
It should be at least a part of the base for the decision: As I said,
the simpler it will be on the node side, the less bug there will be on
the node side, and the less bug there will be on the node side, the
less bug there will be on the client side. But as you said, it's you
who will do most of the work, so it's up to you.
