On 2/5/07, bbackde at googlemail.com <bbackde at googlemail.com> wrote: > 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.
After thinking about this I came to the conclusion that a PersistentBlah should always introduce new items, and not update existing 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 :) I revert my meaning :) > > > > > 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. Finally not a good idea: if a request was SUCCESSFUL and then it is removed from the queue, why should the node send a GetFailed with Removed=true? We need a message PersistentRequestRemoved to keep it consistent and simple! > > > > > > 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.
