Places2, thinking out loud...
By glazou on Tuesday 10 February 2009, 19:08 - Mozilla - Permalink
Webslices/Webchunks. My secret dream was a smooth integration of Webchunks into Places so the user's personal toolbar could contain Webchunks just as it can contain bookmarks, folders, feeds, microsummaries. But adding a new consumer to Places is anything but a trivial operation because Places' consumers are almost hard-coded in Places itself... I think Places should evolve into a consumer-agnostic architecture where bookmarks and all others are only consumers of Places and do not require a single line of code added to Places itself. A well documented and easy to understand API could trigger a new class of extensions to Firefox that other browsers could not immediately or easily afford. Places2 ?
Comments
I agree. I've been working on integrating an extension with places, and trying to put our folder in the library sidebar or even to have your own image for the folder is very nontrivial. Also keeping track of your folder when someone has a sync extension is installed is almost impossible.
Places1 might very well be able to do what you want, if you would provide more detail. From what I can tell, there's no need to add a "consumer" to Places to do what you want. You should pop in to #places, or email me with more details. I'd be glad to help you more with Places, and talk more about your Places2 ideas
Richwklein: Yes, adding custom nav items to the Library is not very flexible. Improving library extensibility is a goal for Firefox 3.2.
About your sync comment: It should be a problem at all - most sync extensions do sync annotations, which are a great way to add custom metadata to bookmarks, history, etc. Feel free to email me at dietrich at mozilla dot com if you need help with your extension.
I have some specifics on difficulties in Places
I've been working on an extension to sync places bookmarks with delicious and other sharing services.
http://github.com/mikeal/pushmarks/...
It was not trivial to say the least. The hardest part I would have to say is doing any kind of search. The query API was just impossible for me to understand and I ended up just using PlacesUtils to push all the bookmarks to a JSON file and read it back in (yes, it's hacky but it works).
There are a lot of niceties in PlacesUtils but they all operate on "places nodes" which is totally detached from the Places service which operates primarily on id's. This makes PlacesUtils generally useless if you're doing anything that is triggered by the observer service which returns id's.
Still, it's a world easier than the old bookmark system. And even with all these issues, I have a nearly working extension after about 10 hours of work.
In general I found working with Places just as difficult as working with most of the XUL platform. Interfaces and observers are not easy, simple, or intuitive APIs and warrant good abstractions if we want to see broader use. It doesn't "feel" like javascript. FUEL, as an example, was a great effort at making the platform feel more like the kind of javascript most web developers are used to.
mikeal: yes, working with anything that gets even remotely near XPCOM immediately feels alien to js web developers. could say that about interface-based programming and web developers generally maybe
FUEL got part way there, but is still too simple for many extension developer's use-cases - they need to reach outside of it far too often.
maybe the next step is pushing FUEL forward to be more full featured, and thinning the abstraction between it and Places proper. not sure yet, thanks again for the feedback