Re: Pointers to whois++ documents

[Alan Emtage <[e-mail]>]

>      PROTOCOL CHANGES
> 
>      1) The HOLD attribute has changed from a unary to binary operator. You
>      need to say "hold=true" rather than just "hold".
> 
> I fail to see the point of this, what is the problem with just having
> an unary operator? Are you proposing that some servers may have hold
> on by default?

The problem is one of parsing the input. As constructed in the current
draft the parsing of unary constraint operators is difficult (and I
believe "impossible" in some cases in that the results are ambiguous). 

>      2) The LIST, COMMANDS and CONSTRAINTS, commands create "virtual"
>      templates for their responses. For example, the CONSTRAINTS command
>      returns:
> 
> I assume "virtual" means that you can't construct a search query to
> find them. If this is true then that's OK.

Correct. It's just so that the client will have a consistent response
format to deal with so that you don't have to have separate parsers for
different kinds of responses.

>      3) System responses (starting with a '%') have status numbers, following
>      the conventions for the FTP protocol (rfc 959). Values of 100 - 199 are
>      informational and temporary, 200 - 299 are status values and permenant.
>      300 - 399 are non fatal temporary warnings, 400 - 499 are permenant
>      warnings and 500 - 599 are fatal permenant errors.
> 
> Well if you are going to have 3 digit codes are you going to define
> what the other digits mean or is this just a silly way of emulating
> VMS's I, W, E, F severity levels?

This is to allow system responses to have a language-independent format.
We will need to define what each response means (much like FTP, SMTP,
NNTP etc) but this is much easier than having to deal with
english-language system responses which would then have to be translated
or strcmp()'d to see what the response is. It also gives much more
flexibility to handle expanded response modes.

>      4) ABRIGED responses are given after 10 hits, not 2 as in the RFC. The
>      WAIS search system does not permit the determination of what element of
>      the inital search query caused a match, so they do not return this value.
>      It is possible that very few search engines will allow this and this may
>      need to be reviewed. The ABRIDGED responses here have degenerated to
>      HANDLE responses.
> 
> I think it would be better, until smart formatting whois++ clients are
> widely deployed, to retain the 2 item limit between (default) full and
> abridged/handle. If you increase it to 10 that means that potentially
> you can get 10 full listing flashing by you on your screen. That's
> fine for people who have window systems with scrollbars but there are
> still a huge number of people with dumb terminals. This is bad enough
> with something like archie where only the last matches (probably not
> in your country) will be left on the screen but with whois++ it
> probably means the hit you wanted has scrolled off the top :-)

That's why we have file redirects, script(1), more(1), and
less(1).


-- 
-Alan

------------------------------------------------------------------------------
Alan Emtage,				"The Left in Canada is more gauche
Bunyip Information Systems,		 than sinister"
Montreal, CANADA			 -The Economist

[e-mail]
Voice: [phone]		Fax: [phone]