Re: proclamation of intent

[Bob Manson <bmanson@juniper.net>]

In message < Pine.GSO.4.10.9908231158010.20253-100000@sys4 >, Rick Macdonald writ
es:
>The fields and enums should have human-readable Help strings (multi-line
>allowed?), and these strings need to be available to the client.

Agreed. I haven't done this yet but it's a trivial thing to add; I'll
probably just put it to the grammar after I'm done with this message.
Nothing will actually use it yet.

>I would like that all configuration stuff is read and parsed by GNATS, and
>when sent to the client, it is formatted and written by GNATS (gnatsd)
>such that the client just parses it and doesn't have to check for errors

I had little intention of just dumping out a config file, although it
may make a bit of sense to do this for the network protocol.  The
parser's already in the network client, so there's little to be gained
to split it all apart in N different ways.  But none of this is
"written in stone"; I'm certainly open to other people's suggestions!

I honestly don't have any idea what the configuration info as sent to
clients will look like.  I think now would be a great time for people
to make suggestions as to what they'd like to see.

The info that needs to be presented is really in two parts.  The first part
will simply be field definitions, including but not limited to:

	name
	(optional) internal field designation
	type of data stored in field
	additional per-data-type options:
		enum list
		regexp qualifier
		default match type
	default value
	help string

name:	The name of the field. This will not include the '>' or ':' separator
	characters.  This may be different from the name used in the PR
	to mark the field (and if so, the PR field string would need to
	be included as well).

internal field designation: Some fields are internally used by GNATS, such
	as Category, PR Number, etc.  There needs to be a mechanism to
	relate these internal fields to their actual definitions.

type of data:  text, enum, date, multitext.  Some text fields may be
	further qualified by a regexp that they must match.

	I've given some thought to adding a "numeric" type as well, and I 
	think it's essential to limit this basic information to a manageable
	set, so any other ideas need to be implemented soon.

per-data-type options:  This should be fairly obvious; for an enum, the
	possible values need to be listed, etc.

	"default match type" simply refers to the type of search that is done
	by default.  Currently some fields in GNATS are set up as "must match
	entire field" when a regexp is used on that field, while others are
	"may match any part of field".

default value: Obvious.

help string: A human-readable description of the field.

The second part would be the actual "presentation format" of the PR,
at least in terms of field order.  This may optionally include a
template such as that used by edit-pr, although this would be fairly
useless for a web-based client; it might also include suggested field
headings for a forms-based client.  I'm leaving this part rather
vague, since I don't honestly know what would be most useful.

Again, I am certainly not proposing any particular format; I'm totally
open to suggestions for this.  I'm also trying very hard to not break
existing clients that have hard-coded field information.
						Bob