[resending from right email...] On Thu, Apr 9, 2009 at 12:53 AM, Aaron Boodman <[email protected]> wrote:
> On Wed, Apr 8, 2009 at 11:55 PM, Tim Steele <[email protected]> wrote: > > Nice stuff. I think this question primarily applies to bookmarks, but how > > does the API deal with keeping states consistent? By the time a > getBookmarks > > callback or an event reaches the listener (in a separate process), the > > bookmarks referred to may have changed or been removed already; even > while > > the listener is processing the event itself. E.g something like > > updateBookmark would need to handle this at least minimally; if you > update a > > bookmark that has been deleted, do we recreate it and encode that in a > > BookmarkInfo somehow, or should the API callback with a null BookmarkInfo > > (may be tough to do correctly at the right times)? > > The question applies to every object in the system (every object could > disappear or change in an incompatible way while you hold it). True. I hadn't looked closely at the other APIs before raising that and was assuming they were mostly immutable :) I see that's not the case. Still, I think realistically updating a bookmark is most common. > > > My current thinking for this particular case is that the most > reasonable thing to do is to drop the update on the floor and write an > error to the console. > > There are two ways a developer can get here: > > * He received a remove event for an ID, but ignored it, then sent an > update. That is his fault, error makes sense. > > * There was an actual race. The ID was valid when he sent it but got > removed while in flight. I think this will be vanishingly rare in real > life. Any API we add for it will not get tested. Printing the error to > the console in this case is unfortunate because it isn't really an > error on the developer's part, but if we have enough people writing > extensions that somebody legitimately sees this case, I will be stoked > :). IAWTP. But I can think of some extensions people will write where this will pop up. If you're trying to send bookmarks over the wire to, say, another instance of the same extension somewhere in the cloud via a service, the window of FAIL opens up. There are recourses the extension can take in most every case, but as I know you already know from past experiences with this wonderful hellpit it'll be really hard / impossible to just _verify_ that two endpoints have the same data let alone keep things in a consistent state. I don't have a simple way to improve this though and I agree we shouldn't overcomplicate things here for the minority. Doesn't solve everything, but maybe provide some programmatical "why" info to the extension when we fail / drop write operations. It could be as simple as having the callback parameter type having an extra success boolean. That is a slippery slope though given the different ways things can succeed/fail. Anyway, just mentioning! > > > - a > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
