Hi everybody,

One of the things that still needs to be finalized for FF2 is the
parameters for querying the history system. I'm interested in what
parameters people think would be most useful so that I can make the
query system accomodate them.

You can see the current query object here:
http://lxr.mozilla.org/seamonkey/source/browser/components/places/pub...

You can also specify some options (see nsINavHistoryQueryOptions in the
same file) which allows you to specify some more parameters.

To review, the overall structure of a query is that you pass in an array
of these query objects. Everything inside one query object is ANDed
together, and then each query object is ORed. This will likely not
change, as this is able to cover most cases (I vaguely remember some
theorem that states any boolean expression can be expanded this way as
long as you have a NOT operator).

The major things missing is the ability to specify visit counts, express
NOT operations, express < or > operations.

There was some talk about implementing the query as a property bag, with
some parsing rules for names, but from an API perspective I don't like
this. I was thinking something like:

SetQueryParameter(parameter, operator, value);

and then having constants in the query object defining each type of
parameter and operator we would have. Thus, you would say

query.SetQueryParameterStr(query.PARAMETER_HOST, query.OP_EQUALS,
                            "mozilla.org");
query.SetQueryParameterInt(query.PARAMETER_VISITCOUNT, query.OP_LESS,
                            5);

For all pages from host mozilla.org visited less than 5 times.

Then we would delete all the properties on the query object. You would
only be able to set each parameter once per query object, and subsequent
sets would overwrite the old ones. Not all parameters would support all
operators.

We would have to change the serialization of place: URIs (queries). Most
things could be kept the same, except for the things currently
accessible by flags (like "uriIsPrefix" would go away and we'd get a
separate URI_PREFIX parameter that would be mutually exclusive to the
URI parameter). This will not affect most things.

Are there important query cases that this can't handle? Are there any
special queries that you're particularly interested in writing a smart
query folder for?

Brett

Brett,

what's the difference between
(foo.hasDomain) and (foo.domain != null)
?

Same for the other string properties.

Should the code be able to match http://www.bar.com/foo/baz.gif? Thus
having domainIsHost == false and uriIsPrefix ==  true?

Axel

The point is that this old API will go away, so don't worry about it too
much. hasDomain just checks if the fomain is empty. Some of the other
items have more complex existance rules, they all have one for
consistency. uriIsPrefix does not matter in your example, since you
didn't specify a URI. URI is different than domain.

This might be a good "call for comment" thing to broadcast on MDN, too.

-Ben

What does "uriIsPrefix" actually mean?  Is "javascript:x" a prefix of
"javascript:xhtml" for example?  Is "http://web.mit.edu/b" a prefix of
"http://web.mit.edu/bzbarsky"?

-Boris

Good idea, Ben. BTW, d  o we have a reference page in place for Places on
MDC yet? If not, we should create one and make sure that final
documentation is placed there as we move forward.

cheers,
mike

--
mike beltzner, user experience lead, mozilla corporation

Yes and yes.

I have created and stubbed out: http://developer.mozilla.org/en/docs/Places

-Ben

Probably worth documenting that clearly; the examples made it look like prefix
was a "can be a base URI for" thing...

-Boris

The whole point of this thread is that this interface is getting redone.
I'll probably make two separate parameters called URI_PREFIX and
URI_MATCH or something. It just would not make sense to define them
both. I'll try to write good documentation for each parameter.

Brett

I may have assumed too much of the context that i was reading right now.

The question I had was, can I query for:

subdomains of foo.com AND
path startswith "somedir/"

thus matching http://foo.com/somedir/hi and
http://www.foo.com/somedir/hello, but not matching http://www.foo.com/bar.

Axel

I see what you mean. No.

:) startsWith matches the whole beginning of the URL. This is efficient
because we have an index over the URL. We can also efficiently query for
hosts, so that query is efficient. With your query, we would have to
brute-force parse each URI, extract the path, and compare.

Just a note: there is some small possibility that I'll remove the
capability to efficiently match host names. Currently this is supported
by having an extra column in the database of host names written in
reverse with an index. However, it makes the file bigger (we store each
host name once in the URL and once separately), the extra index makes
inserts slower, and there's not out-of-the box uses of this query. If I
determine that the size/space this capability is using is not
insignificant, I will probably drop the host.

Brett