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)
Just updated the API based on some of the previous comments. I'm not sure what you mean by containment -- but here's what I'm thinking of as far as containment/ownership/serialization. Each container will be responsible for deciding which of its children should be serialized, if any. This means that containers from some providers (let's say the History Smart Bookmark Provider) will decide not to serialize their children, but will only serialize themselves (e.g. some stored query indicating "sites visited today"). I added some stuff to the Provider interface that changed the basic interfaces to "Item" and "Container", instead of just "Node" (even though they both derive from Node), and also some attributes to indicate whether it makes sense for a user to create an item or a container from that particular provider. (e.g. the History provider would allow the user to create containers, but it doesn't make any sense for the user to create items... the provider itself would just use the simple item implementation for representing the children that are to be displayed).
Upon deserialization, that part will be read in, and the container implementation can then do the actual "what sites were visited today" query. Something like live/RSS bookmarks would probably choose to serialize their content to act as a cache; if the feed site can't be reached, the cached items would be used, otherwise they would be deleted and replaced with the newer items.
That brings up an UI issue; some bookmark providers, like the "sites visited today" bookmark container, would really want to update whenever the user opens up the bookmarks menu or otherwise views bookmarks. (Update live, if some kind of sidebar is open?) But we don't want to block opening the menu for whatever network or other computation has to happen... so we need that stuff to be able to update asynchronously, while the menu or other UI is open. We should be able to do this using Neil's new template stuff (I plan on implementing a custom template data source for bookmarks).
(I'm writing up a separate Bookmarks Design Rationale document that should explain some of this stuff in more detail and give more examples, should have that done tomorrow.) -- VladVukicevic 20:38, 6 Jul 2005 (PDT)
Reintroduction of a Necessary feature
- why can't you use Alt-Enter to access the properties of a bookmark?
- I really like Firefox but I find that it is missing one key feature for me to transition from Mozilla 1.7.12 to Firefox 1.5.0.4, that is the lack of the same Mozilla "Bookmark This Group of Tabs" feature in Firefox.
Now I know that Firefox has a "Bookmark All Tabs..." option but unlike Mozilla it creates a folder just like any other and has an option to "open in tabs" at the bottom of the folder. I can see why they did this and it would be nice to be able to enter a bookmark group to access only one tab... Yet it is something that is really rarely needed and could be done by hovering over the tab group for a short while.
Now this might seam like a minor gripe considering all the other positives Firefox has over Mozilla, Yet I am truly addicted to the bookmark group in Mozilla and there are a few main reasons behind this:
- it looks different than the other folders and is easy to distinguish
- one simple click on the bookmark group to open it
- The "Bookmark This Group of Tabs" defaults to show you the file tree (for lack of a better term) giving you a quicker way to save the bookmark group.
I REALLY would LOVE a solution to this Please help.... Thanks! -- UKPhoenix79 03:36, 15 July 2006 (PDT)
