[NNTP] Compressed LIST (and other commands) answers

[Clive D.W. Feather]

Urs Janen said:
> > I think a generic command is an interesting idea and definitely better
> > than creating a bunch of new separate commands.
> 
> but what about response code then? (i.e. HDR returns 221, OVER 224 and LIST
> ACTIVE 215 on success) - with seperate commands we could keep this.

In order to be compatible with NNTP section 3.2, we'd have to do something
like:

[C] COMPRESSED STAT <45223423 at example.com>
[S] 202 Underlying command successful with single line response
[S] 223 0 <45223423 at example.com>
[S] .

[C] COMPRESSED LIST ACTIVE
[S] 203 Underlying command successful with compressed multiline response
[S] 215 list follows
[S] <compressed data>
[S] .

[C] COMPRESSED LIST WIBBLE
[S] 204 Underlying command failed
[S] 501 Unknown LIST keyword
[S] .

with the response always being multiline.

> just adding compression for multiline server -> client responses would be a
> big win

How big?

If it's only LIST ACTIVE and OVER, how much do these get used?

> (and if compression/decompession speed is an issue one could go with
> LZO (<http://www.oberhumer.com/opensource/lzo/>) as this is where users
> spend time to wait for responses from the servers;

Would an NNTP-specific compression be better for these two cases?

> I'd like to see BASE64 encoding instead of YENC as it's 7bit clean,

That's a bad reason. NNTP connections are 8 bit, so what on earth is the
point of wasting a huge amount of encoding space. BASE64 uses 6 bits per
character; NNTP is capable of carrying about 7.9.

If we have to go in this direction, let's have a well-designed compressor
that squeezes out the maximum usage of the channel.

-- 
Clive D.W. Feather          | If you lie to the compiler,
Email: clive at davros.org     | it will get its revenge.
Web: http://www.davros.org  |   - Henry Spencer
Mobile: +44 7973 377646