On Apr 18, 2011, at 12:41 PM, Marvin Humphrey wrote: > The 'mailto:' example is the only one that's problematic with #4, the > NoMatchQuery option, though. And it's pretty esoteric -- how many times do > people actually type/paste mailto links into search boxes?
Not often, though it happens. I wouldn't worry overmuch about it. > The others are all solvable by tightening up the parser: > > * Currently field names must match /[0-9A-Za-z_]+/. We should require > them to be identifiers, i.e. they must not start with a number: > /[A-Za-z_][0-9A-Za-z_]*/ > * QueryParser should use single-token lookahead to enforce that field name > constructs must be followed by something sensible. And if it's not, what then? What if it's sensible but the field doesn't exist (or is private)? > I think we ought to consider the fact that QueryParser turns > 'PHP::Interpreter' into field name 'PHP' and term ':Interpreter' a bug, and > address it with bugfixes rather than a new feature. +1 to fixing bugs first. > The behavior after > applying the fixes will be to produce a phrase -- just as with option #3 -- > but the internals of QueryParser will be cleaner. Excellent. >> And at what point would the application of one of the above four solutions >> be applied? I can see arguments for 0.1.0 and 0.2.0. > > This issue should not block 0.1.0, which is almost done. Well, if the handling of PHP::Interpreter is a bug, should that not be fixed before 0.1.0? > We'd probably be voting on 0.1.0 now were it not for the interesting traffic > on lucy-dev diverting our attention. :) Sorry, I suck. David
