Talk:Bookmarks Data API
My suggestion would be to stick with either "ns" or "moz" as the namespace for the interfaces. I know I've written my share of interfaces with other namespaces, but I think that sticking to a common set for the mozilla codebase makes sense. --Darin 21:43, 5 Jul 2005 (PDT)
Sounds good; I'll change it to moz. Most of it is "bmIBookmark" anyway, so "mozIBookmark" looks better in any case. I'll update the interfaces soon. -- VladVukicevic 12:46, 6 Jul 2005 (PDT)
This looks cool Vlad, I'm excited by the application possibilities this API rework might allow for. It would be useful to see a high level overview of the different components of the system. A discussion on the different "type" properties would also be useful... it looks like nodes can have a string type property, but what is this used for? To identify provider? that it is a container? something else? Should one be able to locate a provider for a bookmark given an id? There are also integer types used for the two roots the FE uses right now (main root and toolbar root), the documentation near here references a |getBookmarkByType| method that I don't see declared. --Ben 11:49, 6 Jul 2005 (PDT)
The "type" field is intended to identify the provider type, but it probably should just be a pointer to a bmIBookmarkProvider. There's a few comment bugs I'll fix shortly as well -- the bookmark provider's name property should say "as displayed in the UI", not URI, and the comment about |getBookmarkByType| should instead be talking about |getKnownBookmark| (I realized that "type" was way too overloaded). One case I'd like to handle is where a certain bookmark type was being handled by an extension, but the user disabled/uninstalled that extension. I don't think we should lose those particular bookmarks, though maybe we just won't display them. I also might ditch the whole string serialization/deserialization bit, and just require all providers to store whatever extra data they have in each node's property bag, and just serialize that way directly to storage. --VladVukicevic 12:46, 6 Jul 2005 (PDT)
Another thought - if I want to be able to build a single view to manage Bookmarks and History and perhaps other datasources (e.g. Bonjour) does this provide a mechanism to talk about containment? Is that what bmIBookmarkProvider is? (are History/Bonjour Bookmark Providers?) it was not clear if the contents supplied by Bookmark Providers was serialized into the Bookmarks Datasource... the Livemark example doesn't really illuminate because presently livemark content is serialized into bookmarks.html. --Ben 15:37, 6 Jul 2005 (PDT)