durusmail: quixote-users: Pipelining the async HTTP server
async HTTP server included?
2004-01-06
2004-01-06
Re: async HTTP server included?
2004-01-06
2004-01-06
async HTTP server included?
2004-01-06
Re: async HTTP server included?
2004-01-06
async HTTP server included?
2004-01-07
Re: async HTTP server included?
2004-01-07
2004-01-07
2004-01-07
2004-01-07
Re: Licensing
2004-01-07
2004-01-07
2004-01-07
Pipelining the async HTTP server
2004-01-07
Re: Pipelining the async HTTP server
2004-01-07
2004-01-07
2004-01-08
Re: Pipelining the async HTTP server
2004-01-08
2004-01-08
2004-01-08
2004-01-08
quixote.server.medusa (Re: Pipelining the async HTTP server)
2004-01-08
quixote.server.medusa
2004-01-08
2004-01-12
Re: quixote.server.medusa (Re: Pipelining the async HTTP server)
2004-01-13
Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Re: Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Resolved! Was Re: [Quixote-users] Re: Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Re: Resolved! Was Re: Re: Problem with using quixote.server.medusa vs. standalone medusa
2004-01-14
Pipelining the async HTTP server
2004-01-08
2004-01-08
Re: Pipelining the async HTTP server
2004-01-08
2004-01-08
2004-01-06
Re: async HTTP server included?
2004-01-06
Pipelining the async HTTP server
Jim Dukarm
2004-01-08
---------- Graham Fawcett answered and spake unto them: ---------
> 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.

After re-browsing chunks of Medusa and its documentation last night, I
came to the conclusion that rewriting Pierre's server to beef it up
would just end up reproducing a subset of Medusa. Sam Rushing did a
very thorough job.

> 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.

Medusa in its present form (0.5.4) works well. It is a toolkit
for building all sorts of servers, and the full generality is not
needed for Quixote.  Probably that generality, together with the
partly archaeological nature of Medusa's documentation, is the main
obstacle for those who might want to use it. As Dave Kuhlman recently
showed, it is not difficult to get the latest version of Medusa and
set it up for use with Quixote, as long as you have a clear idea of
what needs to be done.  Thanks for writing out the details, Dave!

I think it would be good for Quixote to put the relevant parts of
Medusa into a subpackage of Quixote, as Graham suggests, so that we
can have a comprehensible, easily maintainable, production-strength
HTTP server readily available for "instant demo" use, for application
testing, and also for embedding in certain types of applications.

---------- Thus spake amk: --------------------
> Another thing I'd like to see, and will write if Medusa goes in: a module
> that runs a Quixote application on a random port and then uses
> webbrowser.open() to run a browser pointing at the application.  This would
> make it really easy to write portable little applications.

A "dynamite" idea.  That would be useful for the Quixote demos, too.
It might even be a handy development tool.

Jim Dukarm
DELTA-X RESEARCH
Victoria BC Canada



reply