WEP 103 - Relative Bookmarks
- Champions: Edward Lee <edilee at mozilla dot com>
- Status: Draft
- Type: ?
- Created: 2009 Aug 13
- Reference Implementation: bug 506768
- WEP Index
Introduction and Rationale
The bookmarks engine is the only provided engine that relies on the server to give records in depth/index order that maps directly to the tree structure of folders and bookmarks.
WEP 102 - Partial Sync Download would like to sort incoming records by their "interestingness," so bookmarks then couldn't rely on parent folders and predecessor bookmarks to exist before a bookmark is created.
Also, because the index is an absolute position of where a bookmark should sit in a folder, any movement (addition/deletion) of bookmarks requires siblings of the source/destination of the bookmark to update their index value. This results in many update writes on the server to track the new absolute position of each sibling bookmark.
When uploading a BookmarkItem record, store the GUID of the parent and predecessor bookmark/folder and bookmark data. Compared to now, this adds an additional predecessor field and removes the depth or sortindex fields.
When applying an incoming BookmarkItem, check if both the parent and predecessor exists by GUID.
- If both exist, create the item under the parent, behind the predecessor.
- If only the parent GUID exists, insert the item under the parent and add an annotation to remember the predecessor GUID.
- Otherwise, place the item in Unsorted and create two annotations; one for the parent and one for the predecessor.
After creating the item, if it's a folder, search for items that have a parent annotation of the just-added GUID. For each of those, remember its GUID and move it under the the folder and remove the parent annotation.
With the GUIDs of the just created item and any re-parented GUIDs, search for items that have those GUIDs as the predecessor annotation and move them behind the predecessor and remove the annotation.
On notifications of bookmark create, delete, or move; the tracker needs to additionally track the successor as changed, so that a new record is uploaded with the correct predecessor. Moved bookmarks have 2 successors that need to be updated (before/after).
Note, parent deletion causes places to delete all the children first, so nothing special needs to be done.
Alternatively, we can additionally track an array of meta records for those that only need to update the parent/predecessor values.
- Server: Allow a top-level predecessor property for WBO
- Until then, we can just put the predecessor as part of the payload..
- Fetching records out of depth/index order