Places hooks for extensions
Mike Shaver
http://wiki.mozilla.org/Places:Query_System but was told that it was
better to start a thread here, so I shall!
Some Places hooks that I think would permit some great extensions:
1) An optional "search" handler on custom containers.
It would be very useful, I think, for custom containers to be able to
perform a search themselves, for cases in which reflecting the entire
corpus of possible results into the bookmark system isn't feasible. An
example would be "mounting" Flickr as a subfolder, and having searches
do tag matches; it would be good to avoid returning the entire
Flickr-known universe to the query engine for it to process.
2) Express and sort/order/limit by weight.
Less importantly: being able to express a weight for a query hit, and
to filter or order based on weighting. To reuse the Flickr example, a
query for "weather service" would return a high weight for something
that I had tagged with one of those terms, a medium weight for
something that a Flickr-friend of mine had tagged, and a low weight for
something that had only been tagged by other people. They might also
scale the weight according to how many of the queried tags were hit (or
the different terms might be run as different queries over the various
sources and aggregated by the query engine, I suppose) or by how many
times that tag has been applied.
3) Observer system for Places store changes
Being able to get a notification when a bookmark (or history entry,
probably want a flag to mask those off) is added/removed/changed would
help with bookmark syncing and other kinds of indexing and
"self-profiling". Otherwise, I suspect we will end up with nasty hacks
to hide the "real" bookmark tree in a custom container somehow, to get
those notifications.
What say ye, Places kin?
Mike
Brett Wilson
> 1) An optional "search" handler on custom containers.
You mean so you can type something into the places search box and get
back local and flickr results? (in your example) I'm actually not sold
on how great this would be. Why not just search Flickr? There's a search
engine box that will hopefully be much easier to use in the next
release, why not just use that.
All searching is currently synchronous. It would not be OK for your
fickr search plugin to suspend the whole UI thread while it goes out
over the network and searches flickr.
We would also need to add UI so you had the option of *not* searching
flickr if you wanted to search for something private or didn't want to
wait. How would this work? The current search box says
All Bookmarks and history
Current collection only
Adding flickr plus the ability to *not* search flickr.
All collections
All Bookmarks and history
Current collection only
Flickr
Which seems like overkill to me.
I'm not opposed to the ability to do this. But, it sounds like a whole
lot of work with many backend and UI design implications that nobody has
on their schedule for something that's purely theoretical. Since there
is no cool application that we'll all be using, even if we do it, it
will be insufficiently tested and will probably work badly.
I think we should hold of for Firefox 3 to consider this. If people are
writing places extensions (I actually don't think there will be many)
and somebody has a good idea that makes us all go "Yes! I want that!"
*then* we should do it. Otherwise we shouldn't take time off from making
the current design fast and stable to make it work.
> 2) Express and sort/order/limit by weight.
This sounds fine but we can not do it without a good working
application. It has implications for everything, including the backend,
tree view, and front end. Unlike the previous suggestion, these
implications aren't too serious, but it would still need a lot of
testing, which requires an application many people are using.
> 3) Observer system for Places store changes
This already happens.
Mike Shaver
group...curious. Apologies for the lack of appropriate quoting, as
doing that by hand in the Groups interface is painful. I hope the
context is clear enough.)
Brett wrote:
> Mike Shaver wrote:
> > 1) An optional "search" handler on custom containers.
> You mean so you can type something into the places search box and get
> back local and flickr results? (in your example) I'm actually not sold
> on how great this would be. Why not just search Flickr?
Is the use case clearer if I say "del.icio.us" instead of Flickr? I
don't want to use the del.icio.us search engine plugin, because I want
results for my "local" bookmarks and history as well as the pages that
I've tagged in del.icio.us, or that people have "sent" me via
del.icio.us, or that my friends have tagged via that system.
I think we're going to hurt if we do synchronous searching as data sets
get large anyway. The GTK guys are making their file picker asynch in
the next version for similar reasons, and as we make it easier for
people to add entries to this store (explicitly, or implicitly due to
the history integration) I think we're likely to have pauses that are
well above the human perceptual threshold -- 100ms? That's what the
phone companies use, I think.
This sort of integration is not purely theoretical, I should point out.
People have been beating their heads against the Firefox 1.x bookmark
model and custom RDF datasources and other such pain for a long time
trying to make such things work, and I think it's an important sort of
extension to support, given the focus in Fx2 on information
organization and retrieval.
I don't see the UI design implications, though: I would expect that the
custom container's AsyncSearch mechanism would return exactly the same
sorts of result elements that are produced by the query system, and
they would be presented in the same way. As with HistoryResult
(http://wiki.mozilla.org/Places:Results), the extension could be
required to implement nsITreeView or whatever else, if we want. I
mainly care about "possible", since "easy" can be helped with JS
utility libraries and such later on.
(Aside: should that not be nsITreeModel instead, and
nsINavHistoryResultModelObserver, since the result set doesn't actually
perform the visualization? Or is it really deciding how the results
should be presented, rather than just providing the result data?)
I don't quite understand your point about needing an application that
many people are using to design the APIs, though -- with Places itself,
design decisions about these very search mechanisms were made without
an application that many people were using. We can certainly look at
existing remote bookmark and URL-annotation/classification/etc. systems
today and imagine pretty clearly how they might be integrated into the
user's view of their "internet Places". Even our existing extensions,
like del.icio.us and even LinkedIn, are pretty useful as inspiration
for the sorts of minimum integration requirements for that large class
of "how I manage and classify and manipulate the URLs that I care
about" applications.
It would also provide a useful hook for things like the full-text
search capability we discussed briefly in the last Firefox2 meeting
(you'd "mount" the search-of-history, or perhaps even GDS, as a new
bookmark folder, and get the results included, etc.).
Restricting the scope of searches is probably useful for a lot of
cases, not just avoiding query leakage (which is pretty common anyway,
given how people extract such information from search engine
referrers). Given that Places provides a hierarchy, and that you can
have a container in multiple places in that hierarchy, "search on
subtree" seems like a decent enough model there, and that would let
users (likely guided by extensions) divide their search targets
usefully. (I also expect we'll see someone write an extension to weld
our search-engine support into Places queries somehow, which would be
great experimentation to permit as a way to inform what we do with
Places in Fx3.) Almost all search interfaces that operate on a
hierarchy provide such a capability, no?
I think a lot of people _are_ going to want to build these sorts of
extensions for Places. I get a ton of pings about it from people
investigating extension development. And I think that our schedule,
Places complexity, and novelty of our approach mean that we're unlikely
to nail this problem on the first try, so we should help extension
authors (and therefore users) try different approaches.
Weighting of search results seems like a critical aspect of providing a
good search experience, and again an area where I think permitting rich
extensions is of high value to us. What would you need to see in a
"good working application" that could be provided without staring down
the barrel of a chicken-and-egg problem WRT the lack of a weighting
API? I can spend time designing use cases for such an API if that's
what is needed, but I want to make sure that that's what we're looking
for here before I invest a lot of time in it.
I have no shortage of partners and extension authors to ask about their
Places-integration desires, if it's more specific use cases for these
things that you want; the 3 items I listed in my original post were the
result of distilling many such use cases and inquiries into what I
thought were the minimal primitives. (They also put the responsibility
for most of the heavy lifting in terms of interaction design and
mapping the Places model to a given service on the shoulders of the
extension author, rather than trying to provide a richer set of APIs
via Places itself, which seemed like the right division of labour given
the Fx2 schedule and the scale of the extension community.)
Great to hear about the observer stuff; I know that Myk was looking for
something like that for his microsummary work, too.
Sorry this was so long, but I don't have time right now to minimize it.
;/ I can try to summarize it later if that's helpful.
Mike
Jedora Shi
Good!
Ben Goodger
2) Express and sort/order/limit by weight.
>
> This sounds fine but we can not do it without a good working
> application. It has implications for everything, including the backend,
> tree view, and front end. Unlike the previous suggestion, these
> implications aren't too serious, but it would still need a lot of
> testing, which requires an application many people are using.
Implementing our own search ranking this way, allowing bookmarks to
bubble up to the top in some instances, just as with "typed" history
entries, is one application that already exists within our charter.
-Ben
Ben Goodger
> (Aside: should that not be nsITreeModel instead, and
> nsINavHistoryResultModelObserver, since the result set doesn't actually
> perform the visualization? Or is it really deciding how the results
> should be presented, rather than just providing the result data?)
To continue this aside into a tangent with its own subject line...
The nsITreeView interface really bugs me. Why? Because it contains view
_and_ controller functionality and assumes both are tightly coupled to
the data model. Thus nsIXULTreeBuilderObserver or whatever abominably
long interface name it is, etc, and other such clones throughout the
codebase.
IMO, nsITreeView should be split into nsITreeView, and nsITreeController.
With respect to this specific instance, it should be possible to show
async results in any view, so the nsINavHistoryResultViewer interface is
a better one to use since it provides methods for inserting, removing
and changing items.
Mike (and others), would you be interested in doing a more comprehensive
review of the existing places APIs? They're in
browser/components/places/public
-Ben
Brett Wilson
don't see the schedule and testing resources available in the current
roadmap. Maybe this is just a result of me already having too much to do
and probably being the gating factor on many of these enhancements.
There is a bunch of custom container stuff in there already that
literally nobody has used (not even me--it's totally untested!) and
nobody outside of our circle of like 3-5 people has asked me about. I
put it in for the file browser bookmarks feature where directories ge
magically expanded in your bookmarks menus which may or may not get
implemented.
I do not want to add even more things that will not get test coverage
before we release. An insufficiently tested feature that has not been
given a lot of use in nightlies will not be any use to extension
authors; we are actually doing them a disservice by putting that stuff
in because they'll waste tons of time banging their heads against bugs.
Ben mentioned that we want to have search ranking for our own results.
That's great. But there's no bug for that, it isn't on my schedule, and
I'm already swamped. Parts of the current API are unimplemented or
broken, and those will take priority over these enhancements.
To do this stuff we will need extra people or time. For the features
designed for extensions, we will need somebody willing to write an
extension that many of us want to use so that our places enhancements
can get adequate testing. The extension and the places enhancements
would be done in parallel.
Brett
Mike Shaver
> Just to be clear, I think these are all good ideas and goals. I just
> don't see the schedule and testing resources available in the current
> roadmap. Maybe this is just a result of me already having too much to do
> and probably being the gating factor on many of these enhancements.
Thanks for clarifying that; I took your initial response to be a lack
of interest in the capabilities themselves, not (appropriate!) concern
about resources.
> There is a bunch of custom container stuff in there already that
> literally nobody has used (not even me--it's totally untested!) and
> nobody outside of our circle of like 3-5 people has asked me about. I
> put it in for the file browser bookmarks feature where directories ge
> magically expanded in your bookmarks menus which may or may not get
> implemented.
Man, I wish I'd got my list of stuff to you before they did; they
could be my untested hooks instead. :)
I'm not surprised that nobody has asked about it, given how recently
Places has been available in a general form for people to build
against. I'm quite serious, though, when I say that I'm seeing more
interest in extending Places to do the sorts of things that require
these hooks than in pretty much any other such part of Fx2.
> I do not want to add even more things that will not get test coverage
> before we release.
Nor do I, and I would in fact philosophically be inclined to remove
things that don't have good test coverage as we reach beta2, in terms
of hooks and the like.
> Ben mentioned that we want to have search ranking for our own results.
> That's great. But there's no bug for that, it isn't on my schedule, and
> I'm already swamped. Parts of the current API are unimplemented or
> broken, and those will take priority over these enhancements.
Is that necessarily the case? I'd rather see us decide where to spend
future API-development effort based on the value of those APIs, and
not on a "sunk cost" basis because they were sketched out earlier on
an optimistic basis.
I'll spend some time this weekend looking at the places code to
generate a SWAG for the effort involved in adding these sorts of
hooks, so that you and other people who know better can tell me how
far off I am. :)
If someone can give me a lead on how the existing Places code is being
tested, I'll try to scope the incremental effort for adding these
elements to that as well.
> To do this stuff we will need extra people or time.
Or we need to trade something else off, indeed. If we reach agreement
that these hooks are desireable (that is, there aren't objections to
the design itself), then we should figure out how they fit into the
prioritization of Firefox2 work, versus other Places (and non-Places)
features. It may well be that these are P3 items, and that the core
Places team has too many P1 and P2 items to get to them according to
the current plan, but getting to that point of agreement is helpful in
enlisting others to provide assistance.
> For the features
> designed for extensions, we will need somebody willing to write an
> extension that many of us want to use so that our places enhancements
> can get adequate testing.
I don't think any of the things I proposed are just useful for
extensions, though we may not ship anything in Firefox 2(.0) that uses
them, as part of the default install. But I am indeed hot on the
trail of people who would write extensions and/or test code for such
hooks, based at first on the people who asked about the use cases that
led me to design the hooks!
Mike
Mike Shaver
> Mike (and others), would you be interested in doing a more comprehensive
> review of the existing places APIs? They're in
> browser/components/places/public
I am certainly interested, though I'll be hard-pressed to do that
myself much before the end of April. If I find myself in there and
have comments, I'll be sure to post here.
Mike