On 2/5/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Mon, Feb 05, 2007 at 01:29:22PM +0100, bbackde at googlemail.com wrote: > > On 2/5/07, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > > On Sun, Feb 04, 2007 at 09:38:47PM +0100, bbackde at googlemail.com wrote: > > > > If FCP2 want to provide clients an easy access, then the following > > > > changes are needed: > > > > > > > > Answer to a ModifyPersistentRequest should not be a new > > > > Persistent<blah> with all values, but a ModifiedPersistentRequest > > > > message with only the changed values. Otherwise the client has to do > > > > all syncing and searching for really changed values. > > > > > > I don't get this. Why not just have a Persistent<blah> ? Surely less > > > messages is the simpler solution? > > > > It makes the processing for clients easier. And I think this should be > > the goal. Consider the code of a client: the client gets a new > > PersistentBlah message, and if he already have the request in its > > table/list, then he now have to compare all values (knowing which ones > > could change) against the new values. > > 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. 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 :) > > > A ModifiedPersistentRequest message would contain only the changed > > values, making life for clients easier. Also its more simple for > > clients to get a concrete answer to a request, not a common answer > > like a PersistentBlah. > > > > This is just my point of view, as client developer ;) feel free to > > vote me down. > > I'm not sure I get it, although I am inclined to go with the view of > client devs as a general principle. Obviously what we want is for it to > be as simple as possible an API. > > > > > > Answer to a RemovePersistentRequest should be a > > > > RemovedPersistentRequest, this is a clear answer to the request and > > > > clients don't need to do much investigation here. > > > > > > Or a GetFailed with Removed=true. > > > > See above. Of course the client could figure out what happened with a > > flag but its easier with an own message. > > Well you have to guarantee that the RemovePersistentRequest arrives > *after* the GetFailed - or that you don't send a GetFailed at all. > Sending a GetFailed is backwards compatible, but I suppose that > shouldn't matter too much. > > > > > > Its easy to implement this in the node and I offer to do the changes > > > > and to document them in the wiki. Existing clients are not affected. > > > > > > By all means. > > > > > > > > Please discuss this, and with your answer provide an explanation WHY > > > > you recommendation is better then the given ones, thanks. > > > > > > > > rgds, bback. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFFxymeA9rUluQ9pFARAuxAAKCmHX0eizxk1BEb0Yg7YFTsSQwIbwCgvpMN > e5gnSydk5wS+93pTWBcToos= > =XiaL > -----END PGP SIGNATURE----- > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl > >
