Dave Kuhlman wrote:
> On Wed, Jan 07, 2004 at 01:37:25PM -0500, Graham Fawcett wrote:
>
> [snip]
>
>>It may turn out that a better way to get ourselves an async HTTP server
>>is to strip down the Medusa package to a bare-bones dispatacher/HTTP 1.1
>>request handler combo. I'm a little hesitant about this, though, having
>>never really grasped all the intricacies of Medusa's design. However, if
>>we can do it and stay small (1-2 source files), then Bob's your uncle.
>
> Why not just include Medusa, even un-stripped-down as a
> sub-directory in the Quixote installation?  The distribution of
> Medusa that I down-loaded (medusa-0.5.4.tar.gz) was just 108K.  No
> one complains about that kind of size anymore.


After some thought, I'm leaning in the same direction.

A benefit of reworking Pierre's code instead /might/ be that we could get a
smaller, tighter piece of code: one that was quickly readable and easy to
maintain for future Quixote developers. But having tried to fix the
multiple-requests problem with his server, I'm not sure how small and tight it
will be anyway. It's not that Pierre's code is faulty, it's just that it was
designed with different intentions (to replace SimpleHTTPServer with an
asyncore-based equivalent). To meet our ends, I suspect that a significant
rewrite would be in order. Already we are overlapping into Medusa territory.

Personally I'd vote for including Medusa, but stripped down. Including it gives
us "Works out of the Box", and that's the key goal in my opinion. Stripping it
down makes it more readable and manageable. Of the ~30 source files that
comprise Medusa, only four are required for the HTTP server.

(The four files are http_server.py, producers.py, logger.py and http_date.py. I
left out status_handler because it can be safely removed. Perhaps even
logger.py could be removed since Quixote has its own logging support; and we
only need one or two of the producer classes. That's about 600-800 lines, max.)

Unless Medusa is under serious, active development (?) and there's a sentiment
that their development could benefit us in some way, I don't see any problem
with forking-and-freezing a subset of it, and incorporating it into the Quixote
codebase.

> Are there any problems with Medusa for this use?  Does Medusa support
> HTTP 1.1 completely?

Doubtful... but I'm not aware of any server that makes that claim. Off the top
of my head, HTTP 1.1 added support for expectations, ranges, many cache-control
directives, chunked encoding, and proxy authentication; also some new status
codes (many of which are quite esoteric and are probably never used)...

Many of these features really fall into Quixote territory. Whether or not to
provide cache-control directives is application-specific; similarly with
expectations and ranges; and definitely with status codes! In a sense, we can
never promise a 'compliant HTTP 1.1 server in Quixote' because the onus of
compliance invariably falls upon the web app developers.

I guess I'm less concerned about de jure correctness and more concerned about
ensuring that performance-optimizing aspects are available: persistent
connections definitely qualify.

>
> It would be useful to add a bit of additional documentation in
> doc/web-server.html including a sample start-up script. The qxdemo
> already has a sample script (qxdemo-0.1/scripts/links-server.py).
> If the documentation included "three steps for running Quixote with
> Medusa", wouldn't that satisfy the requirement for "A Medusa-like
> out-of-the-box server included with Quixote".  After all, Medusa is
> very Medusa-like.

Can't argue with that.  ;-)
>
> Even if one of the "three steps" were to down-load Medusa
> separately and unroll it, that does not seem to be much of a burden
> to me, especially if Medusa was available at the Quixote site.
>
> I was able to set up and use Quixote with Medusa.  That's about as
> good a test of ease-of-use as you can get.

You're right, of course. It's almost a no-brainer to put Medusa in place. I'd
still argue for embedding it -- the benefits really are very appealing -- but
the status quo is not that bad!

> Another benefit -- Medusa has been tested rather thoroughly.
> You want it to be "out-of-the-box", but you also want it to be as
> close to industrial strength as possible.
>
> And that also solves the licensing problem.  From another recent
> message:
>
>     "The Medusa license is also the Python license, so no problem
>     there."
>
> But, it would be polite, of course, to ask Sam Rushing about doing
> this.

Agreed, agreed and agreed.

I have enjoyed working on Pierre's code -- as an intellectual exercise, as a
refresher in async programming, and due to the interesting discussion it
provoked on this list. But we're a long way from production quality; and
there's no reason to invent a well-tested wheel.

If there's no great objection, I will prepare a 'quixote.server.medusa' package
that contains only the required Medusa elements (and perhaps moving
medusa_http.py into the package as well?) and recommend we include it in
the next release.

Thanks for your insights, Dave.

-- Graham