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. > 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070205/7bf21d0f/attachment.pgp>
