client info format ideas

[Rick Macdonald <rickm@vsl.com>]

On Mon, 23 Aug 1999, Bob Manson wrote:

> 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.

OK, here's a rough suggestion, just to get some reactions. I've grabbed
these examples from your previous post:

        field "Release-Note" {
                multitext
                query-default exact-regexp
        }

        field "Release" {
                string matching "insert-regex-here"
                query-pr-option "A" "--release"
                network-query-command "RLSE"
                query-default inexact-regexp
        }

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

Looking now, wouldn't it be more straight-forward if all lines were
keyword-value pairs?

What's missing is that type-of-data has no keyword. It could be:

        field "Release-Note" {
                type multitext
and   
        field "Priority" {
		type enum
                enum { ...
  
and                      
                        
        field "Release" {
                type text
                stringmatching "insert-regex-here"

I'm not sure about your "string matching". Are there other sub options to
"string" other than "matching"? If not, that's why I combined it to one
keyword "stringmatching".

The point of this little cleanup suggestion is to facilitate this format:

fieldname "list of keyword-value pairs"

(I realize that the format of the gnats config files doesn't have to be
exactly like the info sent to clients, but it might as well start off
being more similar, I figure!)

Tcl and perl have different list syntax, but the following idea might be
useful for perl as well(?).

For Tcl:

fieldname {keyword {value} keyword {value} keyword {value}}

So, for the fields above:

Release-Note {type {multitext} query-default {exact-regexp}}

Release {type {text} stringmatching {[0-9]\.[0-9]} query-pr-option {A
--release} network-query-command {RLSE} query-default {inexact-regexp}}

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

With this format, I don't even have to parse:

If variable "f" is set to the "Priority" line above:

% array set keys [lindex $f 1]
% array names keys
query-default network-query-command enum type query-pr-option

and now there's an array called "keys" with elements equal to your
keywords.

Note that "enum" is nested:

% puts $keys(enum)
values {high medium low} default {medium}

but I can do the same thing:

% array set enumkeys $keys(enum)
% array names enumkeys
values default
% puts $enumkeys(values)
high medium low

There may be drawbacks with the above, such as restricions on the number
of characters in one line (before an LF or CR/LF). Also, the brace
characters, if they exist in the keyword-values, would have to be escaped.

An alternative might be just a stream of records:

220 List follows.
field Priority
type enum
enumvalues high medium low
enumdefault medium
enumquery-pr-option p --priority
network-query-command PRIO 
query-default exact-regexp
field Release
...etc...
query-default inexact-regexp
.

In this case I've "flattened" the nested enum into the one level of
keyword-value pairs. It's not really much more work to read this and build
my own lists or arrays.

...RickM...