590
edits
Places/AsyncAPIsForSync: Difference between revisions
Jump to navigation
Jump to search
→Notes and feedback on Proposal: Bookmark API Feedback (responding to philikon)
Comrade693 (talk | contribs) (→Notes and feedback on Proposal: Bookmark API Feedback (responding to philikon)) |
|||
| Line 200: | Line 200: | ||
=== No need for "plural" methods === | === No need for "plural" methods === | ||
Due to the way Sync engines work, we have no need for the batch operation methods (insertBookmarks, updateItems) as we deal with each bookmark record individually. We're running this in batchmode anyway. --philikon | Due to the way Sync engines work, we have no need for the batch operation methods (insertBookmarks, updateItems) as we deal with each bookmark record individually. We're running this in batchmode anyway. --philikon | ||
We didn't want runInBatchMode to have magic flags that deal with these async methods. Shouldn't be a problem for the Sync team to deal with this new way. --sdwilsh | |||
=== Types of places items covered === | === Types of places items covered === | ||
| Line 211: | Line 213: | ||
* query (TYPE_BOOKMARK with a place: URI) | * query (TYPE_BOOKMARK with a place: URI) | ||
Note that Sync does not support "dynamic containers" (TYPE_DYNAMIC_CONTAINER). --philikon | Note that Sync does not support "dynamic containers" (TYPE_DYNAMIC_CONTAINER). --philikon | ||
All these are covered, but you may have to roll your own way with annotations. --sdwilsh | |||
=== Interfaces === | === Interfaces === | ||
| Line 226: | Line 230: | ||
Having the parent name in there feels awkward but it would make our code much easier while making the places code only slightly more complicated (I hope). I will have to think about alternatives to our current duping algorithm, but there's probably little alternative to having it match folder names. --philikon | Having the parent name in there feels awkward but it would make our code much easier while making the places code only slightly more complicated (I hope). I will have to think about alternatives to our current duping algorithm, but there's probably little alternative to having it match folder names. --philikon | ||
Decision: keep the parentName. --sdwilsh | |||
=== Predecessor === | === Predecessor === | ||
This is similar to the parent name issue: In order to preserve ordering, Sync maintains the GUID of an item's predecessor in each record. So it'd be good if nsIBookmarkInfo were to contain that info. Bonus points for making <code>updateItem</code> understand this and move the item appropriately. --philikon | This is similar to the parent name issue: In order to preserve ordering, Sync maintains the GUID of an item's predecessor in each record. So it'd be good if nsIBookmarkInfo were to contain that info. Bonus points for making <code>updateItem</code> understand this and move the item appropriately. --philikon | ||
We'd like to just keep it at itemIndex, due to more complicated queries or more queries. philikon says it's possible, but will follow up. --sdwilsh | |||
=== Tags === | === Tags === | ||
| Line 238: | Line 246: | ||
We explicitly ignore the tags folder right now, so it doesn't magically work. Sync uses the tagging service API explicitly. So either we should perhaps start syncing the tags folder (if that does indeed magically work) or nsIBookmarkInfo should contain the tags. --philikon | We explicitly ignore the tags folder right now, so it doesn't magically work. Sync uses the tagging service API explicitly. So either we should perhaps start syncing the tags folder (if that does indeed magically work) or nsIBookmarkInfo should contain the tags. --philikon | ||
OK, we could add a getBookmarkInfoWithTags (or have another argument to getBookmarkInfo) that could obtain tags too. Syncing the bookmarg tags folder wouldn't work out right for things like the iphone client. --sdwilsh | |||
=== nsIBookmarkInfo readonly === | === nsIBookmarkInfo readonly === | ||
| Line 252: | Line 262: | ||
Pretty sure we don't have any need for querying bookmarks by URI. --philikon | Pretty sure we don't have any need for querying bookmarks by URI. --philikon | ||
Let's just drop support for querying on URI. --sdwilsh | |||
=== Missing attributes ignored on update === | === Missing attributes ignored on update === | ||
| Line 263: | Line 275: | ||
Yes, it would be great if missing properties on the nsIBookmarkInfo object would simply be ignored in the update. The same should go for annotations. This means that this API wouldn't allow us to remove annotations, but that's ok since we have no need for it. But we do avoid having to first get all the information before updating it. --philikon | Yes, it would be great if missing properties on the nsIBookmarkInfo object would simply be ignored in the update. The same should go for annotations. This means that this API wouldn't allow us to remove annotations, but that's ok since we have no need for it. But we do avoid having to first get all the information before updating it. --philikon | ||
This shouldn't be a problem. We can add an API in the future for removal of data, but we do not need to in this cycle (2.0). --sdwilsh | |||
=History= | =History= | ||