Bookmarks Data API: Difference between revisions

Bookmarks Data API (view source)

Revision as of 17:38, 6 July 2005

No change in size , 6 July 2005

m

correct grammar

Grantaw

10

edits

@@ Line 3: / Line 3: @@
 To use regular bookmarks and live bookmarks as an example: there would be a provider with a type of "simple" for regular bookmarks, and a provider with a type of "rss" for live bookmarks.
-the simple provider's bmIBookmarkItem implementation wouldn't have much other than just the URI and the name.  It would return true for all canBeContainedBy queries.  The bmIBookmarkContainer would also be straightforward, and would return true for all canContain queries.  For serialization, the container would just ask each child to serialize itself, chain these together, add some data (such as its own name and id), and return.
+The simple provider's bmIBookmarkItem implementation wouldn't have much other than just the URI and the name.  It would return true for all canBeContainedBy queries.  The bmIBookmarkContainer would also be straightforward, and would return true for all canContain queries.  For serialization, the container would just ask each child to serialize itself, chain these together, add some data (such as its own name and id), and return.
 The live bookmarks provider would have its own implementation of bmIBookmarkContainer and bmIBookmarkItem; the container would reference a particular URL (which is what it would serialize, along with maybe information about items that have been visited), and it would create a bunch of bmIBookmarkItems (bmRSSBookmarkItem?) that would have URIs for the individual entries.  bmLivemark would be a bmIBookmarkContainer with readOnly = false and containerReadOnly = true.  Because these are read-only, the canContain/canBeContainedBy values don't really matter.