Laying QuickSearch to rest

[Andreas Franke]

Hi all,

not sure whether my I am supposed to participate
in this thread, but in case you care, here it goes...

Yes, the primary goal of quicksearch was to offer 
at least one easily discoverable way for newbees to 
perform simple bug searches with nothing but a few 
search terms.  Had the Simple-Search form been on 
the front page already at that time, there wouldn't 
have been much motivation to replace it with something 
else.

On the other hand, at least some people who wouldn't
count as newbees found it useful to have more powerful
search options available within this text entry field.
Quicksearch was derived from and inspired by Jesse's
existing javascript tool, and until yesterday, he was 
almost the only one who cared to make design suggestions 
and feature requests.

> How would you feel if we quietly sent QuickSearch off 
> to be with its forefathers?
>
> Now we have a more usable query.cgi, and Myk's full 
> text searching stuff, it seems much less necessary. 

If the primary goal is still met (and having either
SimpleSearch or Myk's full text search on the front
page instead would seem to satisfy it), then replacing
QuickSearch on the front page is fine with me.

If I did not misunderstand him, at least Bradley seems 
to agree with me about the second goal of having a 
powerful search textbox readily available for advanced
users.  So if there is a replacement that is (almost) 
as powerful as quicksearch, then I'm also fine with 
moving quicksearch to contrib, for example.

But note that there are people who would really like to
have something like this at least in contrib, as an 
example for building custom client-side query tools.
See http://bugzilla.mozilla.org/show_bug.cgi?id=102618#c8
(his last name is the same as mine, but that's just pure 
coincidence).

> It's always been a bit of a hack,

Yes, admittedly.  Unfortunately, at the time it was born,
there were no real alternatives in sight.  At least that
was my perception.

> having arcane syntax,

There seems to be consensus that some or even most of the
shortcuts offered by quicksearch are unintuitive.  I have
no problem with this.  But I doubt that the unabbreviated
syntax is that unintuitive.  Let's look at Myk's examples:

> product:Browser

Quicksearch does this.  Default comparison operator is
substring, but in this case it doesn't make any difference.

> component:Foo,Bar,Baz

Quicksearch does this, exactly in this syntax. Again this
is with the substring operator (for each of Foo, Bar, Baz), 
but for long component names, this is really what you want.

> product:Browser/Foo,Bar,Baz

Nice idea.  Quicksearch offers these alternatives:
product:Browser component:Foo,Bar,Baz
product:Browser :Foo,Bar,Baz
:Browser :Foo,Bar,Baz
The last two are not really equivalent, since : without
a prefix searches both in product and component, but in 
practice, they often give the same results.
This could be added to quicksearch, but you have to admit
that it's a special case to combine product and component
info in a single item.  And you can see that the line 
between "arcane" and "intuitive" syntax is quite thin, 
in this case it's " :" vs. "/".

> status:RESOLVED,VERIFIED

Ok, this is indeed a bug in quicksearch (though noone
ever got around to file it).  What quicksearch offers is
to start your query with RESOLVED,VERIFIED. 
If would be indeed a good thing if this were recognized 
anywhere in the query, with and without the status: prefix.

So from what I can see, the basic syntax described 
in quicksearchhack.html (i.e. conditions having the
general pattern of field1,field2,field3:val1,val2,val3)
is a generalization of the "intuitive" syntax mentioned
here (which would be field:val1,val2,val3).

The shortcuts and abbreviations offered may indeed
be considered strange and unintuitive.  From the 
viewpoint of a user, you could simply ignore them,
or even suggest some "more intuitive" alternatives.
I admit that it was probably my fault that the doc
pages focus too much on the shortcuts and too little
on the general syntax (which I think is consistent 
with the one used by Google, btw).

> requiring JavaScript, not being very well integrated, 
> and all that sort of thing.

I think the lack of integration is a consequence of
the JavaScript requirement.  It was long consensus
that the way to solve this was to port it to perl.
I don't think that I should be blamed that this 
never got checked in despite of a perl implementation
being available at http://mozilla.flowerday.cx since 
2002-05-22 (see comments #27, #28 and #76 in bug 70907).
Up to now, it seemed to me that the real reason for this
bug being stale was everyone having more important things 
to do. (And I could fully understand that, don't get me
wrong.) Correct me if I'm mistaken here.

Maybe we can agree that the goal is to have a search box
that is implemented in perl, has relevance-ranked full
text search if you simply enter some search terms, and
at the same time enables advanced users to specify other 
conditions with an intuitive syntax (and suitable shortcuts 
if the "intuitive" syntax is verbose).
My path towards this goal had been to port quicksearch
to perl and then improve it; and of course I would have 
been very happy about the integration of Myk's search,
for example.
The alternative path suggested in this discussion seems
to be to first replace the javascript tool with the
full text search perl tool, and then extend that with
the perl-equivalent of quicksearch in a more intuitive
syntax.
It seems to me that the final outcome would not differ
very much. Insofar I appreciate this discussion as a
step in the right direction.

> The person who wrote it, Andreas Franke, hasn't been 
> around for a while, and it hasn't really been maintained.

That's true.  And in all probability I won't be able to 
devote much time to it in the future either.  The other
question is, what would you expect from a maintainer?
The last patches I submitted have been lying around
since 2001-10-04 (fix #1, bug 102618, comment #6; ok
there is even a better fix available by now), 
and 2002-11-21 (bug 107860, comment #8).  I doubt very
much that this discussion is meant to encourage me to
send all kinds of review requests to various developers.
But again, if I'm mistaken, feel free to correct me.

Cheers,
ghost of afranke ;)