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). 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 :). - a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
