gnatsd output question

gnatsd output question

[Milan Zamazal]

I'm not familiar with Internet protocols, so I need an advice on a
certain gnatsd output.

When a new problem is submitted via gnatsd, its output looks like this:

  subm 
  211 Ok.
  <the report text>
  .
  210 GNATS database is now locked.
  210 PR added.
  210 GNATS database is now unlocked.

or, in the case of failure, like this:

  subm
  211 Ok.
  .
  210 GNATS database is now locked.
  402 Failure reading header
  210 GNATS database is now unlocked.

As you can see above, after submitting the report text gnatsd outputs
*three* status report lines as single messages, the overall result
message is wrapped by the locking status messages.  Is this behavior
and/or format right?  If not, how should the output look?

Thanks for any advice.

Milan Zamazal

-- 
And why?

RE: gnatsd output question

[Marcus Williams]

> -----Original Message-----
> From: pdm@blackbird.zamazal.org [ mailto:pdm@blackbird.zamazal.org]On
> Behalf Of Milan Zamazal
> Sent: 10 August 2001 18:45
> To: GNATS Development Mailing List
> Subject: gnatsd output question
[snip]
>   211 Ok.
>   <the report text>
>   .
>   210 GNATS database is now locked.
>   210 PR added.
>   210 GNATS database is now unlocked.
>
> or, in the case of failure, like this:
>
>   subm
>   211 Ok.
>   .
>   210 GNATS database is now locked.
>   402 Failure reading header
>   210 GNATS database is now unlocked.
>
> As you can see above, after submitting the report text
> gnatsd outputs
> *three* status report lines as single messages, the overall result
> message is wrapped by the locking status messages.  Is this behavior
> and/or format right?  If not, how should the output look?
[snip]

I'd tend to agree with Rick Macdonald that the lock messages are
internal to Gnats so dont need to be displayed (unless they fail).

It may be worth doing something like the FTP specs (RFC 0959?) say and
wrap the three messages inside a multiline result so it becomes (from
what I remember of the RFC):

subm
211 Ok.
.
210- GNATS database is now locked
402- Failure reading header
210- GNATS database is now unlocked

The trailing dash after the result code indicates a multiline
continuation. However, this is wrong as well as we're only interested
in the 402 in the middle so it probably should be

subm
211 Ok.
.
402- GNATS database is now locked
402- Failure reading header
402- GNATS database is now unlocked

Since you can only tell that theres a header error by reading the full
message, maybe more error codes should be added so then we can
exchange 402 for whatever the code is for "Failure reading header".
The multiline reply is then only for interactive/information purposes.

Marcus

--
Marcus Williams - http://www.onq2.com
Quintic Ltd, 39 Newnham Rd, Cambridge, CB3 9EY

RE: gnatsd output question

[Rick Macdonald]

On Wed, 5 Sep 2001, Marcus Williams wrote:

> I'd tend to agree with Rick Macdonald that the lock messages are
> internal to Gnats so dont need to be displayed (unless they fail).
> 
> It may be worth doing something like the FTP specs (RFC 0959?) say and
> wrap the three messages inside a multiline result so it becomes (from
> what I remember of the RFC):
> 
> subm
> 211 Ok.
> .
> 210- GNATS database is now locked
> 402- Failure reading header
> 210- GNATS database is now unlocked
> 
> The trailing dash after the result code indicates a multiline
> continuation. However, this is wrong as well as we're only interested
> in the 402 in the middle so it probably should be
> 
> subm
> 211 Ok.
> .
> 402- GNATS database is now locked
> 402- Failure reading header
> 402- GNATS database is now unlocked
> 
> Since you can only tell that theres a header error by reading the full
> message, maybe more error codes should be added so then we can
> exchange 402 for whatever the code is for "Failure reading header".
> The multiline reply is then only for interactive/information purposes.

Well, the multiline is better than three separate ones but I still would
vote to not show the lock/unlock at all. If a submission fails because the
internal lock fails, there should still be just one line. Something like

402 - Failure locking GNATS database

Think about a successful submission. Nobody needs to see

210- GNATS database is now locked
210- PR added
210- GNATS database is now unlocked

...RickM...

RE: gnatsd output question

[Jasper O'Malley]

On Wed, 5 Sep 2001, Rick Macdonald wrote:

> Well, the multiline is better than three separate ones but I still would
> vote to not show the lock/unlock at all.

FWIW, that's my vote, as well. Unless there's a really compelling reason
to do otherwise, I think displaying reasonably descriptive one-line
responses is the way to go.

Cheers,
Mick

RE: gnatsd output question

[Rick Macdonald]

On Wed, 5 Sep 2001, Jasper O'Malley wrote:

> On Wed, 5 Sep 2001, Rick Macdonald wrote:
> 
> > Well, the multiline is better than three separate ones but I still would
> > vote to not show the lock/unlock at all.
> 
> FWIW, that's my vote, as well. Unless there's a really compelling reason
> to do otherwise, I think displaying reasonably descriptive one-line
> responses is the way to go.

The edit command probably locks the database as well. I don't know if it
also sends messages about the lock/unlock, but it shouldn't either! Are
there others?

...RickM...

Re: gnatsd output question

[Mark D. Baushke]

On Wed, 5 Sep 2001 09:54:17 +0100, "Marcus Williams" <marcus@quintic.co.uk>
wrote:
>
> [snip]
> 
> I'd tend to agree with Rick Macdonald that the lock messages are
> internal to Gnats so dont need to be displayed (unless they fail).

Agreed.

> It may be worth doing something like the FTP specs (RFC 0959?) say and
> wrap the three messages inside a multiline result so it becomes (from
> what I remember of the RFC):

Yes, it is RFC 959.

> subm
> 211 Ok.
> .
> 210- GNATS database is now locked
> 402- Failure reading header
> 210- GNATS database is now unlocked
> 
> The trailing dash after the result code indicates a multiline
> continuation. However, this is wrong as well as we're only interested
> in the 402 in the middle so it probably should be
> 
> subm
> 211 Ok.
> .
> 402- GNATS database is now locked
> 402- Failure reading header
> 402- GNATS database is now unlocked
> 
> Since you can only tell that theres a header error by reading the full
> message, maybe more error codes should be added so then we can
> exchange 402 for whatever the code is for "Failure reading header".
> The multiline reply is then only for interactive/information purposes.
> 
> Marcus

Well, that is not really what RFC 959 says.

|      A reply is defined to contain the 3-digit code, followed by Space
|
|
|Postel & Reynolds                                              [Page 35]
|
|
|                                                                        
|RFC 959                                                     October 1985
|File Transfer Protocol
|
|
|      <SP>, followed by one line of text (where some maximum line length
|      has been specified), and terminated by the Telnet end-of-line
|      code.  There will be cases however, where the text is longer than
|      a single line.  In these cases the complete text must be bracketed
|      so the User-process knows when it may stop reading the reply (i.e.
|      stop processing input on the control connection) and go do other
|      things.  This requires a special format on the first line to
|      indicate that more than one line is coming, and another on the
|      last line to designate it as the last.  At least one of these must
|      contain the appropriate reply code to indicate the state of the
|      transaction.  To satisfy all factions, it was decided that both
|      the first and last line codes should be the same.
|
|         Thus the format for multi-line replies is that the first line
|         will begin with the exact required reply code, followed
|         immediately by a Hyphen, "-" (also known as Minus), followed by
|         text.  The last line will begin with the same code, followed
|         immediately by Space <SP>, optionally some text, and the Telnet
|         end-of-line code.
|
|            For example:
|                                123-First line
|                                Second line
|                                  234 A line beginning with numbers
|                                123 The last line
|
|         The user-process then simply needs to search for the second
|         occurrence of the same reply code, followed by <SP> (Space), at
|         the beginning of a line, and ignore all intermediary lines.  If
|         an intermediary line begins with a 3-digit number, the Server
|         must pad the front  to avoid confusion.

So, if you want to use this style of semantics, the error number must
be the same for the first and last lines of the response. The last
line of the response MUST NOT contain a '-' after the number.

In practice, most servers use the same number- as a prefix for the
message:

	123-First line
	123-Second line
	123-234 a line beginning with numbers
	123 The last line

So, even if this method were to be adopted, it should probably NOT be
generating more than one return number as for the database lock and
unlock steps.

	Enjoy!
	-- Mark

Re: gnatsd output question

[Milan Zamazal]

>>>>> "RM" == Rick Macdonald <rickm@vsl.com> writes:

    RM> The edit command probably locks the database as well. I don't
    RM> know if it also sends messages about the lock/unlock, but it
    RM> shouldn't either! Are there others?

OK, all commands, except for the special locking commands, should be
silent about successful (un)locking now.

Thanks for help.

Regards,

Milan Zamazal

-- 
Free software is about freedom, not about free beer.  If you care only about
the latter, you'll end up with no freedom and no free beer.