From mboxrd@z Thu Jan  1 00:00:00 1970
From: Rick Macdonald <rickm@vsl.com>
To: Bob Manson <bmanson@juniper.net>
Cc: gnats-devel@sourceware.cygnus.com
Subject: Re: proclamation of intent
Date: Wed, 18 Aug 1999 12:36:00 -0000
Message-id: <Pine.GSO.4.10.9908181250580.26990-100000@sys4>
References: <199908181821.LAA02046@tristam.juniper.net>
X-SW-Source: 1999-q3/msg00003.html

On Wed, 18 Aug 1999, Bob Manson wrote:

Great news!

> The plan is to have all information that describe fields live in a
> struct (currently it's all done as extensions of PR_entry, tho this
> will probably change), rather than hard-coded throughout the sources.
> This work is mostly complete.  Some fields have special meaning to
> gnats, such as Number, Category, Submitter, State, Last-Modified,
> etc. and thus their presence will remain hardcoded, but wherever
> possible fields will be user-configurable, and it will certainly be
> possible to add new fields via a configuration file.

Sounds good.

> The clients will need to obtain the list of valid fields and their
> datatypes by doing appropriate queries.  Perhaps it would make sense
> to add these sorts of functions to query-pr, tho it might be a better
> idea to have a separate program to do it instead.  Such a client would
> also be able to do basic field validation (verify that the provided
> data is valid for an enumerated field).

At this point I can't tell which would be better yet.

> I'm beginning to wonder if it makes sense for the user to invoke
> query-pr directly.  That is, it may make sense to move some amount of
> the current functionality that is in query-pr into another program,
> and have query-pr be a script or some other program that does
> appropriate formatting of output.

As above, I can't tell yet.

> As a specific example, the various query classes that are currently in
> query-pr don't exactly make sense to me in a more generic context.
> That functionality can be easily achieved by putting an appropriate
> script on top of a query-pr-like program.

By "query classes" do you mean "full", "sql", etc?

> Obviously there will need to be a configuration file that describes
> the field structure.  That's essentially the main issue I need to
> resolve now, by coming up with an appropriate design. I'm thinking
> something along the lines of:
> 

> 	field "Priority" {
> 		enum {
> 			values {
> 				"high" "medium" "low"
> 			}
> 			default "medium"
> 		}
> 		query-pr-option "p" "--priority"
> 		network-query-command "PRIO"
> 		query-default exact-regexp
> 	}

This seems OK.

> 	index {
> 		path "path/relative/to/GNATS_ROOT"
> 		fields {
> 			"Submitter"  "Responsible" "State" "Confidential"
> 			"Severity" "Priority" "Date-Required" "Quarter"
> 			...
> 		}
> 		separator "|"
> 	}

GNATS would then dynamically decide if any given query required only index
fields, or if the entire PR text had to be read? It does that now, but
it's hardwired to know that all but multitext fields are in the index.

> For now, I will also have a query section that will look something like
> 
> 	query "Full" {
> 		fields all
> 	}
> 
> 	query "Summary" {
> 		printf ("%8s %-8.8s %-8.8s %-9.9s %-9.9s %-8.8s %-10.10s %s",
> 			"Number", "Responsible", "Category", "State",
> 			"Severity", "Priority", "Submitter", "Synopsis");
> 	}

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"
                {
        }

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?

> This is probably all "a bit verbose", but I like files where I can
> just look at them and have a good idea of exactly what's going on.

Of great interest to front-end writers is the format that query-pr and
gnatsd would use to send the above info to the client. Obviously, where
the above examples refer to external admin files, GNATS would send the
expanded field info, and _not_ a reference to any of these files. 

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?

> The new options will come in when new fields are used.  Obviously the
> current scheme of single-letter options or specific network commands
> for queries is not extensible or practical; instead, query-pr will have
> options such as
> 
> 	--field-Content --equals "foo"
> 	--field-Last-Modified --is-less-than "some-date"
> 
> I haven't decided the exact syntax of this, but that's the basic idea.

Seems basically OK.

> I'd like to be able to specify inexact matches versus exact matches,
> and strings versus regexps too.  Maybe I should give up on the idea of
> trying to do this as a set of options, and make it full expressions.

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?

On the other hand, I think I know what you're after. Tcl, for example, has
a list search command (lsearch) with mode switches of -exact, -glob and
-regexp.

> I've already added the ability to have boolean expressions to query-pr:
> 
> ( --release "3.3" --and --submitter "bar" ) --or --release "3.4"

Cool!

> These changes will necessarily make the network clients incompatible
> with old servers, and vice-versa.  I don't see much reason to try and
> make this work.

Agreed.

...RickM...