Moving a bookmark should be as simple as changing it's parentId.
-Nick

On Thu, Apr 9, 2009 at 5:01 AM, Mohamed Mansour <[email protected]>wrote:

> Very nice, according to bookmarks, it would be nice to have
> showInShelf(bool) or something like that. Can we have helper classes such as
> moving the bookmarks around? Since the tree storage algorithm is there,
> would be nice to just use it instead of implementing it ourselves.
>
>
>
> On Thu, Apr 9, 2009 at 3: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).
>>
>> 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to