Allegra » Blog Archive » Let’s Twist Again

Let’s Twist Again

Good blog rants have the same effect than sexy magazine covers: they attract readers. Since the publication of Not Yet Another …, readership of my blog doubled, jumping from below 200 visits a day to 400 and growing, with peaks above 800.

Will it work twice? Will I get more of that peer review I’m craving for if I were, for instance, to compare Allegra and Twisted support for HTTP clients?

I know, that’s bad.

Le temps ne fait rien à l’affaire

Slaying Medusa a little bit early, Glyph reminded me that we were allready in 2006. Well, speaking of how time flies by, more than five years after Twisted debut, its web client is still under development. Isn’t an HTTP client the first and most important feature you would expect from a network programming library?

So, why did it take Twisted more than five years to get an HTTP/1.1 client?

And still get it all so wrong.

Twisted Interfaces, Complicated Implementations

Read Twisted sources and you may understand why. Skip the documentation, go directly have a look at the project tree of packages, sub-packages and modules:

http://twistedmatrix.com/trac/browser/trunk/twisted/

You can say “Flat is better than nested” once … and move on to greener pasture. Or look closer and open the module that implements Twisted new HTTP client:

web2/client/http.py

There I found two serious problems.

One can’t be fixed because it is buried deep into twisted core. The second won’t be fixed until Twisted developers change their mindset.

Orthogonal Cruft

First, there are the kind of methods wich clearly indicate that Twisted is, well, just asyncore but twisted so that programmers and their programs have to waiste time to adapt to the fantasy of protocol and transport decoupling:

def registerProducer(self, producer, streaming):
    self.transport.registerProducer(
        producer, streaming
        )
	
def unregisterProducer(self):
    self.transport.unregisterProducer()

Twisted is littered with "orthogonal" interfaces and implementations that mostly degrade performance without adding usefull functions for their applications. They are supposed to make all sorts of wonderfull thing possible, yet they somehow keep to get in the developer’s way.

Appless Mindset

The second problem is the way Twisted provide support for client channel management. Basically, channels themselves must callback their manager. You can clearly see how wrong it is by the added class (and instance!) required to make it work when there is no manager:

class EmptyHTTPClientManager(object):
	
    def clientBusy(self, proto):
        pass
	
    def clientIdle(self, proto):
        pass
	
    def clientPipelining(self, proto):
        pass
	
    def clientGone(self, proto):
        pass

What’s the purpose of a client manager in a networking library if not to manage channels for different protocols and many applications?

Protocol programmers should not have to worry about the client manager when writing their client channel. And both client managers and channels should be reuseable by application developers.

Single purpose managers and channels have nothing to do in a library.

They belong to the application.

Can’t fix it

The web2 Twisted API is still cut at the wrong articulation. Protocol and transport are decoupled without benefit for applications, and the client channel management interface is walking on its head, with thigh coupling of channels and manager (and from the wrong perspective!).

Twisted core is neither simple nor complex.

It is complicated. Made of sophistications developed on simplism. And complicated sources are not just hard to apply. They also perform poorly, beeing both too simple and too complex for their application.

Can it be fixed?

No.

Don’t Fix Something That’s Not Broken

Because, Twisted is allready "fixing something that was not broken".

There is one simple way to do it right, and it is obvious even to Belgians. In Python it has been Sam Rushing’s way, since 1996.

It just needed finalizations, stallable producer and collector to be adapted for network peer applications. Here is the implementation of an HTTP/1.1 client API provided by Allegra:

http_client.py

as a simple mix-in of Async_chat, TCP_client_channel, Pipeline and a MIME_collector.

Practical Interfaces

This module implements three classes: request/response, pipeline channel and client manager:

from allegra.async_loop import dispatch
from allegra.collector import Loginfo_collector
from allegra.http_client import HTTP_client, GET
	
http = HTTP_client ()
pipeline = http ('planetpython.org')
request = GET (pipeline, '/rss20.xml') (
    Loginfo_collector ())
    )

All three can of course be assigned an asynchronous finalization, and like Twisted request and channel, they can be continued asynchronously:

from allegra.loginfo import log
def finalize_request (request):
    log (
        request.mime_collector_lines,
        request.http_response or '000 No Response'
        )
request.finalization = finalize
del request
dispatch ()

but with significantly less overhead and complication.

To Program Applications

HTTP/1.1 pipeline channels can be instanciated and managed directly by their applications or shared and managed by an HTTP_client instance that takes care of asynchronous DNS name resolution, pipeline wake-up and inactive timeouts in a sensible way.

Also, development of HTTP client application is made easy by the simplicity of what is instanciated: an async_chat dispatcher with tcp_*, mime_* and pipeline_* methods or attributes, in one flat namespace.

Last but not least, the client manager can provide the same services seamlessly to different type of derived channels, because it does not require them to implement its own interfaces.

Conclusion

If you liked Allegra’s http_client.py, have a look at the rest of the library. See how flat it is. Some modules are complex but most are the simple same old thing, updated for new peer applications.

If you are a Twisted developer, don’t take it personaly.

Errare humanum est, etc.

This entry was posted on Wednesday, April 26th, 2006 at 12:50 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

20 Responses to “Let’s Twist Again”

elhackin Says:
April 26th, 2006 at 2:28 pm
Ok
the client-side doesn’t please you

and the server-side of twisted ?
Glyph Lefkowitz Says:
April 26th, 2006 at 4:20 pm
You’re making Twisted’s web client look a lot more complex than it actually is. Rather than comparing web2, which is considerably more advanced but unreleased and unstable, let’s look at the clunky old web1 API:

#####

from twisted.web.client import getPage
from twisted.internet import reactor

d = getPage(’http://planetpython.org/rss20.xml’)
def gotXML(xml):
print len(xml), ‘bytes of xml’
reactor.stop()
d.addCallback(gotXML)

reactor.run()

#####

Other than that, though, your comments are on the money. Twisted’s web client support really is embarrassing. It sure would be nice if, rather than running off to maintain a completely abandoned event loop, someone like you would come around and help us improve it … ;-)
foom Says:
April 26th, 2006 at 5:07 pm
Your criticism of the HTTPClientManager is off base, but I’ll forgive you not understanding the purpose, since it is not finished and has no documentation.

“”"What’s the purpose of a client manager in a networking library if not to manage channels for different protocols and many applications?”"”

Well, not that. :) The HTTPClientManager interface is defined only to allow the appropriate notifications of state change of HTTP clients to be sent to a client pooling implementation.

Instead of submitting requests directly to a client, you submit it to a pool which automatically instantiates a client with itself as the manager if necessary, and sends off the request. The pool manager needs to get notified upon the listed state changes in each of its managed connections, so it knows when it is allowable to send more requests along that channel.

The “empty” class is pretty much a placeholder, as the http client pool has not yet been written.
Laurent Szyster Says:
April 26th, 2006 at 6:44 pm
Wow, it works!

At least partially, because I’m still waiting for you Twisted Minions to read *my* code and make the kind of harsh critics that could improve it ;-)

But, I suppose that since I shot the first round, I’ll have to give your questions and comments the priority.

Somebody named elhackin asked “and the server-side of twisted ?”

Well, it’s pretty much the same thing isn’t? Twisted too is a library to do peer networking, not just either client or server. I have not yet investigated the server API in depth, but it rests on the same core which I definitively don’t like … as much as I like asynchat.py, that is.

Although I read:

http://twistedmatrix.com/trac/browser/trunk/twisted/web/http.py

and all I can say for the moment is that it works.

To foom I would reply that my criticism is far from offbase, Glyph noted that. There is a problem of perspective in Twisted web2 client manager interfaces. I suggest you look at:

http://svn.berlios.de/svnroot/repos/allegra/lib/tcp_client.py

and

http://svn.berlios.de/svnroot/repos/allegra/lib/dns_client.py

for a TCP client manager and Pipeline API that do not require to implement hooks in the channels managed.

It is obvious that Twisted web is more stable but less advanced than web2 but having only an HTTP/1.0 client in 2006 and not beeing able to move forward may be a sign that there is either something flawed deeper in the library or that it grew too fast too big. Call me a conservative, but when it comes to fundamental API, I’m ultra-cautious.

So, to Glyph, I’ll say that my work on this fork of Medusa may be a point of comparison and a source of inspiration for Twisted developers, but I don’t have the time to do much more than peer review of Twisted sources. It’s hard enough for me to improve the Standard Python asyncore’s interfaces I allready know and apply.

Regards,
Jean-Paul Says:
April 26th, 2006 at 10:30 pm
You keep saying HTTP is a fundamental requirement of a network library. Do you realize that HTTP is just one of the many things Twisted covers? Twisted’s web libraries aren’t fantastic mainly because no one has actually bothered to make them so. People are far more interested in IRC or FTP or DNS or Jabber or ICQ or MSN or OSCAR or telnet or SSH or vt102 or ident or SMTP or NNTP or POP3 or IMAP4 or SIP or SOCKS or whatever. That the web code in Twisted has come so far with so _little_ developer time devoted to it is actually a strong endorsement of Twisted, not a point of embarassment.

As for constructively criticising Allegra, it just doesn’t do anything interest enough to merit more than five minutes commenting on a blog post. Thoughtful code review takes a lot of effort that I would rather spend improving a useful project, rather than an ill-conceived also-ran.
Bruce Eckel Says:
April 26th, 2006 at 11:33 pm
I just spent 1.5 weeks working with Twisted and, although the documentation definitely has holes in places, the library itself worked very well. I didn’t run into any bugs, which is unusual for me. So I’m a fan.

There are designs within Twisted that appear to be undergoing fundamental architectural changes that I suspect stem from experiences the team has had. I look forward to seeing the results.
Laurent Szyster Says:
April 27th, 2006 at 2:11 am
To Jean Paul:

“You keep saying HTTP is a fundamental requirement of a network library.”

And indeed it is. The web protocol is the lingua-franca of the Internet and if they provide a network API most applications often use HTTP or piggy-back it because it is so pervasive. Wether it is a Web 2.0 service like del.icio.us or a P2P network like Gnutella’s.

It’s a good thing to have an asynchronous Python library for DNS, FTP, SMTP, NNTP, POP3, IMAP4, SIP, SOCKS, ICQ, MSN, OSCAR, SSH and telnet (or whatever …). But not if they are all of the same quality than the HTTP implemention found in Twisted.

“As for constructively criticising Allegra, it just doesn’t do anything interest enough to merit more than five minutes commenting on a blog post. Thoughtful code review takes a lot of effort that I would rather spend improving a useful project, rather than an ill-conceived also-ran.”

That’s harsh, but not much substantiated. Allegra may be ill-conceived (although I disagree with that) but it certainly is not an “also-ran”. And you sure won’t find out how usefull it may be until you actually read and/or test it.

To Bruce:

Twisted works and it has been reviewed and applied for a long time, enough to get stable. Yet, compared with asyncore, asynchat and Medusa, it looks un-necessarily complicated. I believed it was more practical and efficient to improve the standard Python asynchronous networking API rather than try to reinvent it.

The fact that Twisted is “undergoing fundamental architectural changes” may be an evidence that reinventing the wheel is seldom a good idea. Progress is all about marginal improvements, it comes much less often from a revolution.

Look at Python’s support for XML. Since the first Python binding to expat and Greg Stein’s

http://www.lyra.org/greg/python/qp_xml.py

we have seen a multiplication of DOMs and parsers developped. Yet, six years later what has been included in Python 2.5 standard library is … that unorthodox but damn practical element tree that Greg came up first.

I had that gut-feeling about Sam Rushing’s way too.
Andrew Says:
April 27th, 2006 at 2:33 am
Given that for you HTTP is so important, I’m surprised that you don’t see the benefit of transport/protocol seperation, when HTTPS is probably the most obvious example of it.

If you don’t understand why Twisted has some abstractions, why not ask about them, rather than assume they are there just to make life harder? I think you’ll find they all exist for a reason, even if you can’t see it yet.
Laurent Szyster Says:
April 27th, 2006 at 3:05 am
To Andrew:

It’s strange because I don’t understand the benefit of transport/protocol separation because SSL/TLS was specifically designed as a layer *added* on TCP socket. TCP/IP is the transport protocol, SSL is an *application* protocol.

The application is security.

That’s obvious if you consider SMTPS, because in this case the client *must* first perform an handshake *in clear* (using the commands STARTSSL or STARTTLS). Actually, SSL/TLS *may* be applied so that it appears as a transport layer as it does in HTTPS or FTPS, but then a peer TCP/TLS channel implementation may be enough, there is no need to decouple what *is* coupled.

Here is an example of an asynchronous HTTPS server developed with Medusa:

http://svn.osafoundation.org/m2crypto/trunk/demo/medusa054/https_server.py

which demonstrates that there is in this case no need to decouple HTTP and SSL/TLS in HTTPS. Hence, that there are probably not benefits to do so either.
Andrew Says:
April 27th, 2006 at 4:52 am
The obvious benefit is that rather than having 85 lines of code that largely duplicates the TCP case, you can just do “reactor.listenSSL(…)” instead of “reactor.listenTCP(…)”. Ditto connectSSL and connectTCP. The HTTP logic needs to know nothing about which of SSL.SSLError or socket.error or whatever to catch. The HTTP certainly doesnt want to know about portability issues of different socket errors between different platforms. The transport abstraction gives a consistent interface to multiple possible byte-stream transports.

Twisted also supports SMTPS and its STARTTLS command. The TCP transport in Twisted can do the SSL handshake and transform itself into an SSL one if asked. But again, the SMTP code deals with the logic of the SMTP protocol, not how the bytes get delievered to it. (It can always ask the transport if it’s SSL and if so what the client certifcate and so on is if it cares about transport-specific features, but if it doesn’t care, well, it doesn’t have to care).

Being able to run HTTP over named pipes and write protocols that interact with serial port transports the exact same way you write any other byte-stream protocol is just a bonus ;)
Joachim König-Baltes Says:
April 27th, 2006 at 4:16 pm
The problem with all these asynchronous IO handling frameworks (or libraries/solutions/…) is that they force the user [of the framework] to split up the sequential nature of the processing into snippets which get called by the
framework when it detects an event. And these snippets have to store/restore
their internal state into instance variables at the borders. This make the
code unnecessarily cluttered and hard to understand, especially if you do
not fully understand the details of the framework, e.g. when it calls the
callbacks. Of course, experts of the framework do understand the details
and know exactly when the framework fires, so the applications they write
seem so easy to understand to them (and hard to understand why others
don’t see it).

How could this be overcome? Simply try to keep the synchronous nature of the code but without blocking. Before executing a blocking call, the sequential code calls
a method with the ressource(s) to wait upon and the condition (e.g. r/w) before
continuing.

I’ve implemented this with greenlets (a spin off of stackless, implemented as a CPython Extension module) where the waiting call suspends the current tasklet
and lets a scheduler (written in python) evaluate the ressource conditions (by doing the select/kevent/event and dispatching) and continue the tasklet when appropriate.

There is no need to save the state from local to instance variables
because the sequential code will be continued at the same place where it was
suspended by the “magic” waiting call for a ressource, just like generators in standard python (but these are restricted to yielding to the calling function which is not sufficient for this use case).

Unfortunately my code is not prime time ready but runs rather well for a multicast
upnp server with integrated http server which only uses the basic UDPServer and
SimpleHTTPServer without asyncore/asynchat or twisted and without blocking.
Laurent Szyster Says:
April 27th, 2006 at 4:18 pm
To Andrew:

However I still think that adding SSL/TLS support to asyncore dispatchers (be it for a TCP or UNIX pipe socket) is simpler than Twisted implementation:

http://svn.osafoundation.org/m2crypto/trunk/contrib/dispatcher.py

The whole issue of SSL/TLS decoupling is however quite moot and It’s a bit evil from my part to have waited for somebody else to invoke it (after all I *did* write once an asynchronous HTTPS/SOAP gateway)

First because there is little practical use for secure socket layers over anything else than TCP. Second because for a peer it may often be a wiser and safer choice to leave SSL/TLS implementation outside of the application and instead distribute that CPU intensive process on proxies (using ssltunnel for instance).

And third, when you need to implement secure socket layers in your peer, obviously practicality allways beats purity. Even in Twisted

The existence of a class _TLSMixin in:

http://twistedmatrix.com/trac/browser/trunk/twisted/internet/tcp.py

speaks volume about how SSL/TLS and TCP are actually coupled in its implementation of secure socket layers.

Now, I never wrote any protocol for serial ports, but I would expect those protocols to be of very different applications. I mean serial ports are supposed to drive devices like a console or a USB disk, aren’t they?

Finally, note that asyncore dispatcher API does suite both named pipes, TCP sockets and to some extent regular file descriptors on POSIX systems (including STDIO’s).

Regards,
Andrew Says:
April 28th, 2006 at 4:04 am
“However I still think that adding SSL/TLS support to asyncore dispatchers (be it for a TCP or UNIX pipe socket) is simpler than Twisted implementation:”

I’ll start by noting that comments like “XXX”, calls to deprecated functions like “_setup_ssl”, the fact it lives in the contrib/ directory, and has only the most utterly trivial evidence of testing gives me very little confidence in that code.

Part of the difference appears to me to be that M2Crypto has a significantly different (and largely undocumented) API. e.g. ssl_read_nbio. Compare M2Crypto’s ssl_read_nbio code to Twisted’s _TLSMixin.doRead and you’ll see it has the same logic — the difference here is that Twisted is doing this logic itself, rather its SSL library taking care of it. Ditto for writes.

Also, I think that the large comment and associated tricky code in Twisted’s _sendCloseAlert would apply equally well to this code, but it doesn’t handle it.

Without digging any further, this already accounts for the difference in code size.

“I mean serial ports are supposed to drive devices like a console or a USB disk, aren’t they?”

So? There’s more to life than just networking. Event-driven protocols are a natural way to interact with, say, your GPS plugged in to your serial port, if your framework allows it.

Twisted is primarily focused on networking, but that’s not all it’s good for.

“Finally, note that asyncore dispatcher API does suite both named pipes, TCP sockets and to some extent regular file descriptors on POSIX systems (including STDIO’s).”

Twisted supports STDIO pipes fully, not just “to some extent”. I believe it even does so on Windows now as well.
Glyph Lefkowitz Says:
May 2nd, 2006 at 9:35 am
Twisted’s web support is embarrassing in places, but I should not have said your comments were “on the money” - what I meant was that it’s correct that Twisted’s web support is unfortunately broken in places. The first version of twisted.web is mainly the result of a weekend project I literally wrote when I was a teenager. Yet, according to Netcraft, today it powers over 2000 domains: http://survey.netcraft.com/Reports/0604/

Not a huge number, but it has already outpaced certain legacy servers such as Netscape.

While your comment about the *general* problem was accurate, your analysis of *particular* problems were totally wrong, and foom picked them apart better than I could so I will let his comments stand.

twisted.web2 has been languishing because despite widespread interest in Twisted’s web stack, twisted.web has actually been “good enough” for most people using it, and nobody has yet been willing to invest substantial resources to motivate the current developers or provide their own.

Finally, it is not really accurate to say that dispatcher “supports pipes”. You cannot, for example, call recv() on a pipe, so dispatcher.recv() will simply explode. More importantly, protocol implementations *expect* to be able to call recv(), or other socket-specific methods, so a protocol designed to run over a socket will break if you try to run it over stdin.

Twisted can speak to a socket, to a serial port or to a virtualized connection just as easily. I really actually use this feature of Twisted all the time, it is not a hypothetical benefit. Most recently I’ve used it to embed an actually decent, tested-on-networks message-passing protocol over stdin for use as a job control protocol for subprocesess, but the major advantage of transport/protocol separation is the ability to do things like UDP connection tunnelling for peer-to-peer applications. Divmod’s peer to peer protocol, “Q2Q”, is possible largely because of this separation.

UPnP is not everywhere yet! To have an effective P2P mesh you have to deal with NAT in any way possible, and “any way possible” means multiplexing multiple protocol connections over a single TCP connection, issuing CONNECT commands to proxies, and yes, simulating reliable delivery over UDP. I find it bewildering that allegra is allegedly for “python on peers” and you have not figured this out yet, but I suppose you are in good company. BitTorrent, the most popular “P2P” network in the world, also doesn’t work unless the user learns about port numbers and router configuration.
Laurent Szyster Says:
May 2nd, 2006 at 2:26 pm
Hi Glyph,

Thanks for that long comment. I’ll answer each point.

1. HTTP/1.0 is good enough

As long as you serve one resource per connection or can define the length of each of them. But not if you expect to server Chunked-Encoded resources with no predefined length, or support AJAX clients and any other kind of long-lived pipelining user agents.

Then you will need HTTP/1.1, exactly like I did.

2. Dispatching Pipes

Yes you can dispatch a pipe … on POSIX system at least. That’s what the select_trigger.py module uses on other OS than NT to trigger the select/poll call and thunk back threaded continuation into the asynchronous loop.

Actually, most file descriptor will work with select/poll and can be dispatched, including STDIO on Linux.

3. Serial ports, UDP tunnelling, Virtual Connections, etc …

On POSIX serial ports are just files, you can select/poll them like sockets. You may have to adapt the handle_read and handle_write to support exceptions specific serial fds, but it is possible and probably quite simple (I have not tried that).

And for economic and technical reasons, the only plateform for which you want to write network device driver applications is most probably Linux or anothe free UNIX variant. That’s what I would use to program network appliances, not NT.

Practicality beats purity.

I and probably most network peer developers need not the kind of features that make UDP tunnelling or connection virtualization *apparently* simple.

If your application is hosted on a private and managed network, then you can set up all kind of proxies and tunnels (like SOCKS of ssltunnel) without increasing the complexity of your code and without the development time and performance penalty of doing all that in Python instead of C.

Only applications hosted in a single Internet peer require to integrate connection virtualization or protocol tunneling.

But nothing in the asyncore design prevents that.

You can elaborate pretty complex async_core dispatchers and async_chat collectors wrapping each other like russian dolls. For instance that’s what Allegra’s http_reactor.py module does to collect chunked-encoded MIME body for HTTP/1.1 pipelines. This is a simplistic example of application protocol tunnelling, but it’s as real as another (and possibly of many more real-world applications than UDP tunnelling ;-).

Distributed network resource resolution

Finally, speaking of UPnP and P2P protocols, I suggest you have a deep look at the PNS metabase peer that is the application for which Allegra was forked from Medusa.

First because it’s a good example of asynchronous UDP and TCP multiplexers integrated in a complex statefull peer application and using threads to access synchronous API.

Second because its purpose is precisely to solve the problem of distributed network resource resolution on a public network:

http://laurentszyster.be/blog/pns/

to embrace and extend DNS with a Public Name System, safe for public use and free as in free beer *and* free speech.

Regards,
Glyph Lefkowitz Says:
May 2nd, 2006 at 4:18 pm
1. “HTTP/1.0 isn’t good enough … for Ajax clients …”

Yes it is. Nevow Athena works, QED. Practicality beats purity, as you say.

That’s not to say I wouldn’t *like* an HTTP/1.1 server. twisted.web’s file upload support is distressingly bad. but web2 will get there eventually, and hopefully Nevow’s users won’t notice a major disruption when it does. Again: maybe you could be working on improving web2 rather than writing yet another, different, differently broken HTTP/1.1 implementation.

2. “You can dispatch a pipe…”

Yes, but dispatching is not communicating. Medusa was mis-factored: transport logic in the protocol, protocol logic in the application, everything requires subclassing rather than composition.

3. “You can wrap … dispatchers around … collectors”

You certainly _can_, but that is because it’s so easy to build adapters in Python whiich can pretend to be just about any kind of object, whether they’re sockets or virtual consoles. If you build a serious amount of infrastructure around this, then you are basically re-implementing Twisted anyway - except you still have to declare support for new transports with a combinatorial explosion of inheritance rather than method calls like ‘listenUDP(FakeStream(MyClientThatExpectsTCP()))’

4. PNS

A brief glance at the code reveals this in PNS_circle.handle_read:

# bogus UDP read event triggered by errors like
# ECONNRESET

The logic is repeated in PNS_UDP_peer.handle_read(), but without the comment explaining what’s going on. Further evidence that things are mis-factored within medusa (and therefore allegra): this violates DRY, application code is being polluted with repetitive platform quirks, and you’re not even consistently documenting the repetition.

Furthermore PNS doesn’t emulate reliable connections, e.g. provide a “socket” like API for dispatchers that expect a socket to wrap around. For an example of what I’m talking about, see http://divmod.org/trac/browser/trunk/Vertex/vertex/ptcp.py

You say you want code review of Allegra; well, this is the same review I did before writing Twisted, and my conclusion remains the same: Medusa is a great idea, but fundamentally flawed in its factoring of OS-handling and application-handling logic. This is a problem even on a single platform and a disaster once you have to reliably handle things like winsock. At the time I couldn’t articulate it as “transport/protocol separation” and my first few attempts were little better. The difference between then and now is that my alternative is already implemented now, and you could use it if you were interested in its numerous advantages :)

If you would like more useful feedback on application features like PNS, some docstrings would be nice. Having read all of the documentation and most of the code, I have no idea what any of it is supposed to do.
Andrew Says:
May 4th, 2006 at 3:46 pm
“Here is the implementation of an HTTP/1.1 client API provided by Allegra:”

Btw, I suggest you read RFC 2616, because that isn’t an HTTP/1.1 client. I doubt it’s even HTTP/0.9 compliant.
Laurent Szyster Says:
May 4th, 2006 at 4:40 pm
To Andrew:

“(…) that isn’t an HTTP/1.1 client.”

Did you test it?

If yes I would be delighted to hear about it ;-)
Andrew Says:
May 5th, 2006 at 6:25 am
No, I didn’t test it. I skimmed the source. There are many MUSTs in the RFC that you don’t appear to satisfy. For instance:

“”"All HTTP/1.1 applications MUST be able to receive and decode the “chunked” transfer-coding, and MUST ignore chunk-extension extensions they do not understand.”"”

Or:

“”"For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant.”"”

Or:

“”"Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection.”"”

Did you read the RFC before claiming you had written an HTTP/1.1 client?
Laurent Szyster Says:
May 5th, 2006 at 12:54 pm
To Andrew:

“No, I didn’t test it. I skimmed the source.”

Well, skim again, and be sure not to skip this one:

http://svn.berlios.de/svnroot/repos/allegra/lib/http_reactor.py

which precisely provides chunked-encoding and decoding. As for handling the close signal in a persistent connection, you have a point.

So thanks for the review, even if you appear to do it with a less than friendly purpose ;-)

Le temps ne fait rien à l’affaire

Twisted Interfaces, Complicated Implementations

Orthogonal Cruft

Appless Mindset

Can’t fix it

Don’t Fix Something That’s Not Broken

Practical Interfaces

To Program Applications

Conclusion

20 Responses to “Let’s Twist Again”

adobe writer 9.0

Adobe photoshop freeware adobe photoshop ed free 741.

adobe writer 9.0

download adobe acrobat 9 ed,

download adobe acrobat 9 ed,

adobe premiere elements

download adobe acrobat software

download adobe acrobat software

adobe software multigen v1.0 13 apps

buy adobe professional

download adobe acrobat software

adobe photoshop cs5 portable

discount adobe acrobat

download adobe acrobat software

adobe photoshop free download

adobe writer 9.0

buy cheap software adobe dreamweaver cs5

discount adobe acrobat

adobe premiere database software?

Adobe photoshop freeware adobe photoshop ed free 741.

adobe photoshop cs5 portable

adobe premiere elements

buy cheap software adobe dreamweaver cs5

buy cheap software adobe dreamweaver cs5

buy adobe professional

download adobe acrobat software

buy cheap software adobe dreamweaver cs5

adobe photoshop elements 4.0 for mac

Adobe photoshop freeware adobe photoshop ed free 741.

discount adobe acrobat

difference between adobe reader and acrobat reader;

adobe premiere elements

adobe photoshop elements 4.0 for mac

order downloadable adobe photoshop cs4 extended

download adobe acrobat software

order downloadable adobe photoshop cs4 extended

adobe software lisa beverly?

adobe software lisa beverly?

discount adobe acrobat

order downloadable adobe photoshop cs4 extended

adobe software multigen v1.0 13 apps

download adobe acrobat software

adobe writer 9.0

adobe photoshop cs5 portable

adobe software lisa beverly?

order downloadable adobe photoshop cs4 extended

download adobe acrobat software

discount adobe acrobat

adobe photoshop elements 4.0 for mac

download adobe acrobat software

adobe writer 9.0

buy adobe professional

adobe photoshop cs5 portable

adobe software lisa beverly?

download adobe acrobat 9 ed,

buy cheap software adobe dreamweaver cs5

adobe photoshop elements 4.0 for mac

order downloadable adobe photoshop cs4 extended