Confirmed users, Bureaucrats and Sysops emeriti
792
edits
Talk:Bookmarks Data API: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 10: | Line 10: | ||
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. --[[User:Ben|Ben]] 15:37, 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. --[[User:Ben|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.) -- [[User:VladVukicevic|VladVukicevic]] 20:38, 6 Jul 2005 (PDT) | |||