Places/AsyncAPIsForSync: Difference between revisions

→‎Notes and feedback on Proposal: Address one piece of feedback that I missed before.
(Update proposal based on feedback from mak and remove feedback that was addressed.)
(→‎Notes and feedback on Proposal: Address one piece of feedback that I missed before.)
Line 208: Line 208:
I thought about this, but I'm pretty sure that because we store tags as a bookmark in a different root, Sync will just work magically anyway.  We should confirm this with them though.  I'd rather not add it yet if we can avoid it because this is already a lot of work. --sdwilsh
I thought about this, but I'm pretty sure that because we store tags as a bookmark in a different root, Sync will just work magically anyway.  We should confirm this with them though.  I'd rather not add it yet if we can avoid it because this is already a lot of work. --sdwilsh


getBookmarkInfo takes a nsIBookmarkInfo object, thus we probably don't want all of its properties being readonly.
getBookmarkInfo takes a nsIBookmarkInfo object, thus we probably don't want all of its properties being readonly. --mak
It shouldn't matter.  We don't have to return the same nsIBookmarkInfo object that we are passed in (in fact, for threadsafety reasons, we shouldn't!) --sdwilsh
 
Notice that while passing an id or guid will return a single bookmark, passing an uri is not guaranteed to do so. the same uri can have multiple bookmarks.  what to do here? either don't allow by uri, or return last modified bookmark (that is what we do today) --mak
Notice that while passing an id or guid will return a single bookmark, passing an uri is not guaranteed to do so. the same uri can have multiple bookmarks.  what to do here? either don't allow by uri, or return last modified bookmark (that is what we do today) --mak
Last modified probably works fine, but we should check with the Sync team.  I suspect they might actually care about all cases, in which case, we need to change our approach a bit. --sdwilsh
Last modified probably works fine, but we should check with the Sync team.  I suspect they might actually care about all cases, in which case, we need to change our approach a bit. --sdwilsh
590

edits