[Twisted-Python] HTTP versions
itamar at itamarst.org
Sun Jun 1 23:10:40 EDT 2003
On Sun, 1 Jun 2003 17:54:45 -0600
Andrew Dalke <dalke at dalkescientific.com> wrote:
> I can send a patch, but I don't know the dependencies of clients
> on having a version string over a 2-ple, which is what I would
All backwards compatability has to be in the Request class interfaces -
whatever stuff a end user might be using.
> What about using just rfc822.Message? That's in Python 2.2.
Not good enough - MIME stuff should be stored on disk if its large (i.e.
file uploads). I did it using cgi.FieldStorage, and it was backwards
compatible too, but it broke twisted.web.distrib, which *sucked* :(
distrib needs to be fixed so it gets a stream, and then we can mess with
Request as much as we want.
> I used the wrong term. I said "replacement" when I should have
> said "in addition to". That is, code which would eventually become
> the standard code for Twisted once it requires 2.3 (after all, 2.3
> isn't out yet!)
I'd have to see the code before deciding.
> My major complaint, by the way, is not that there are small problems
> with the code. It's that Twisted duplicates functionality from
> standard Python, when the Python code is just as usable for that
> situation and has fewer problems. And going the other way, the Python
> 2.3 implementation
> doesn't have the "\r\n" workaround Twisted has for handling IE
> problems. If those could be combined, then there are more people
> supporting the same
> codebase, so hopefully fewer bugs, and easier to share experience
> the two.
A lot of this is for historical reasons - Twisted only depending on
1.5.2, and then 2.1. 2.2 support is really new.
> A downside is the dependency on Python releases to fix patches, but
> any bugs at this point will be distributed at the patch level, and
> there's always the possibility of just including the patched code
> with Twisted until the next Python update.
Because we can release Twisted so much faster, we usually prefer to just
> "Backwards compatible" is somewhat of an issue. I don't know which
> methods are published and which are unpublished. Is it expected that
> people will (or do) derive from twisted.protocols.http.HTTPChannel ?
> If so, then can I change the behaviour or simply eliminate the
> headerReceived method? (I would rather accumulate all headers then
> parse them into a Message in one go.) What about the other methods?
Request methods and attributes that users are likely to use is what
Itamar Shtull-Trauring http://itamarst.org/
http://www.zoteca.com -- Python & Twisted consulting
More information about the Twisted-Python