H. William Welliver III wrote:
>Making a change like that in a wholesale fashion represents a backward
> compatibility and/or possible stability issue.

That's why I'm not backporting that change to Pike 8.0.

> The shuffler isn???t a free ride (and I???m not sure that your assertions
> are always true, based on my recollections when we implemented its use
> in Caudium), so it shouldn???t the default mode of operation. 

Well, yes, these assertions were not always true before, but I assumed them
to be true, and after committing the necessary fixes to the Shuffler
recently, they now *are* true.

>I also don???t think the fact that a Backend has been specified should be
> the trigger to use the Shuffler. See my previous comment about
> backward compatibility and stability.

If the updated HTTP.Server.Request is not backward compatible, it's a bug
and needs to be fixed.   AFAICS, it is backward compatible as committed, but
I'll happily accept any bugreports.

I implemented a mini-webserver which does on-the-fly compression using
a backend running on multiple CPU cores (still have to test if this
actually allows me to use significantly more than 100% CPU from Pike).

It works roughly like this:

I'm answering a single GET request, but the answer is the concatenation
of an uncompressed file, some pike program uncompressed text output,
and a precompressed file:

uncompressed file1  --> ShufflerA --> Gz.Pipe.Compress --------> \
uncompressed program output --> ShufflerB -> Gz.Pipe.Compress -> ---> ShufflerC
compressed file2  ---------------------------------------------> /

continued:

--> ShufflerC --> chunked transfer encoding --> socket

>The request class to use is easily specified when creating
> a Protocols.HTTP.Server so I don???t see the need to risk breaking code
> in the wild by modifying the default Request class.

Because there would be a lot of code duplication and it speeds up and
lowers the memory footprint for code using the 8.1 version.

It's not that the Request class is supercomplicated.  The code is
relatively straightforward, so it should be easy to fix if anything comes
up.
-- 
Stephen.

Reply via email to