Re: Please review new control-spec.txt

[Robert Mischke <rtm_public@xxxxxxxx>]

Hi Nick,

> [switching to a text-based protocol]

Ok, I see you reasons. As I said, I'm not against a
text-based protocol, so I think we can just leave it
at that. :)

> Being able to telnet to the control port makes stuff
> far, far easier.
> [...] telling people how to use the controller
> interface is as easy as typing human-readable
> strings.

This is an advantage, indeed.

> Hm.  I took a lead from SMTP here, which uses 250 to
> give values and
> OK responses.  A 259 response type would probably be
> better.

Glad you agree here. Please note, however, that I
pulled the 259 number out of the air; I did not ponder
the numbering scheme on this.

> > (Note: All of this applies to GETINFO as well; it
> > should, of course, get a different response code
> than
> > GETCONF.)
> 
> I'm not sure I believe this part.

The idea is the same as above, to make the message
receiving code as context-insensitive as possible. As
long as we want to conceptually distinguish config and
info values (which makes a lot of sense in my
opinion), the receiver could tell them apart by
- keeping a list of which keywords are in which
category
- keeping track of which command triggered this
response or
- be informed about the category by a different
message code.

In my opinion, the last approach is definetly the most
future-safe, and easiest to maintain one. (This is all
from the perspective of writing user front-ends on top
of the protocol; when using a text terminal, it makes
no difference, because humans recognize the context
anyway.)

> This is signed data; you can't add
> whitespace willy-nilly. You would have to say:
> 
>      C: POSTDESCRIPTOR \
>      C: router foobar 1.2.3.4 9001 0 9030\
>      C: more desciptor data\
>      C: even more desciptor data\
>      C: last line of descriptor
>      S: 250 OK

Granted, it should look this way. I added the
whitespace without much thought; it is not required at
all. 

(On a side note, about the "signed" part: Wouldn't
replacing the "original" line breaks with the standard
CRLF break the binary compatibility anyway? Assuming
that we don't always know about the original line
terminator.)

> Hm.  I wish I had a better idea of what I wanted to
> do here.  My
> current inclination is to stay with the current
> system as "simple
> enough", but I wouldn't mind sanding out some of the
> corner cases.

Well, I think the "escaped line break" feature could
really simplify some things. As I noted in my first
post, it's not just the question of how to end a data
block. It would also remove the need for the "+" and
"-" indicators, leading to a very consistent message
format in both directions.

Yours,
Robert



	
		
___________________________________________________________ 
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de