From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bob Manson <bmanson@juniper.net>
To: gnats-devel@sourceware.cygnus.com
Subject: Re: proclamation of intent 
Date: Wed, 18 Aug 1999 13:13:00 -0000
Message-id: <199908182013.NAA02379@tristam.juniper.net>
References: <Pine.GSO.4.10.9908181250580.26990-100000@sys4>
X-SW-Source: 1999-q3/msg00004.html

[resent to list, I missed a cc:]

In message < Pine.GSO.4.10.9908181250580.26990-100000@sys4 >, Rick Macdonald writ
es:
>By "query classes" do you mean "full", "sql", etc?

Exactly.

>This seems inconsistant. Would this be better:
>
>        query "Summary" {
>                format "%8s %-8.8s %-8.8s %-9.9s %-9.9s %-8.8s %-10.10s %s"
>                fields {
>                       "Number" "Responsible" "Category" "State"
>                       "Severity" "Priority" "Submitter" "Synopsis"
>                {
>        }

Yeah, much better.  Thanks.  I just pulled the printf stuff off the
top of my head.

>This opens an interesting possibility. Couldn't any client then feed
>something similar to the above to [n]query-pr/gnatsd, and thereby define
>it's own query output?

That's the plan.  Either something like the above formatting, or a
simple list of fields to return as output.

>As a start, this format would want to be reasonable to parse as a list in
>Tcl and perl. Perhaps we need client-selectable formats: tcl, perl, sh,
>csh?

I could see that.  Want to make this as simple as possible to use, so
having that sort of flexibility would be important.

I'm also not sure what exactly the clients would need to know, other
than the names of the fields, their datatypes, and probably
information about any restrictions on what values are valid (for enums
the set of enumerated values, regexps, etc.)  Any further thoughts
would be most helpful.

Oh, and there should be a human-readable description of the field.
Don't want to forget that!

Ideally it would be possible for the client to get all of the data
that describes a field, but presenting this in a useful way is going
to be difficult (this quickly turnes into the traditional textual
database metadata problem).

What I want to avoid is getting *too* generic.  Somewhere there's a
rather thin line between "this is a problem reporting/bug tracking
system" and "this is a generic searchable text database that happens
to have some default settings oriented around bug tracking".  I think
that happens about the time you have to try and figure out how to
describe fields other than in very simplistic terms.

The *eventual* goal is to be able to layer this on top of a "real"
database.  But that's off in the future.

>It sounds like you might just use regexps. An exact match of "RickM" would
>need ^RickM$. An inexact (substring?) might be .*ick.*, *ick*, or just
>ick?

Well, sometimes you really want to specify a string, even if it has
regexp characters in it.  Obviously you can escape everything, but
that can be painful (especially for an unknowing user that's calling a
simple client like query-pr, and passing in abbreviations to search
for).

I can also envision different search types for other data types,
primarily numeric fields.  It'd be sorta nice to be able to select
ranges of PRs easily (without having to explain complex regexps to
users), or other types of numeric fields (numeric priorities?  version
numbers or release qualifiers that are actual numbers?)  If you have
that ability, then being able to specify string versus regexp searches
seems like a natural extension.

As another example, perhaps we have several severity levels, and we
want all PRs that are less than serious.  Yes, we can list all of the
less-than-serious priorities out in a regexp search, but it's far
easier and more accurate to specify that we want all PRs less than
serious.

As for the string versus substring match, query-pr currently has
varying behavior depending on what fields are being searched (some
fields trying to match with an exact regexp, others allow matches with
parts of the field).  I'm not sure if this is good or bad (the choices
really seem quite arbitrary) but that's the way it's worked for a long
time.  I'd rather give the user the ability to specify it, perhaps
with defaults specified in the configuration file.

As for when this will be released... I was hoping to get something out
this week, probably without any of the configuration file code but
with a lot of the other changes I've been proposing.
					Bob