From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Manson To: Rick Macdonald Cc: gnats-devel@sourceware.cygnus.com, bug-gnats@gnu.org, bmanson@juniper.net Subject: Re: proclamation of intent Date: Mon, 23 Aug 1999 12:12:00 -0000 Message-id: <199908231912.MAA12266@tristam.juniper.net> References: X-SW-Source: 1999-q3/msg00020.html 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