I think we're making progress, but I'm still not sure about the new
httplib api.  My current worry is that endheaders() behaves very
differently when send_data is false.  My chief concern is that the
__state variable is going to indicate that the request has been sent
when we're really depending on the client to send the header.  In
general, I don't like the public send() method since it's exposing a
raw socket that could be called at any time regardless of the _state
of the object.

What if endheaders() takes body as an optional argument and sends it
along with the headers?  This accomplishes the same basic goal as
returning the header from endheaders(), but keeps the actual sending
of data encapsulated within the http connection.

Jeremy

On Tue, Nov 25, 2008 at 6:13 AM, Kristján Valur Jónsson
<report@bugs.python.org> wrote:
>
> Kristján Valur Jónsson <kristjan@ccpgames.com> added the comment:
>
> I have addressed some issues mentioned:
> 1) I have retained the _send_output() method.
> 2) the endheaders() method now takes an optional argument, send_data
> that defaults to True.  It also returns any unsent data as a string.
> This simplifies any code wishing to send more data.
> 3) The old HTTP class needs no changes anymore.
> 4) I've fixed the test_xmlrpc.py test case to run all the tests on
> windows.  The old concern with "WSAEWOULDBLOCK" seems to be no longer
> valid.
> 5) concatenating the result from endheaders() with the request body is
> valid, in xmlrpclib, because the assumption has already been made in
> send_content() that request_body is a string (str(len(request_body)).
> However, in httplib's request() method, we now special case this.  I
> don't want to complicate the code for what appears to be a rare case.
>
> I chose not to mess with xmlrpclib and make it continue to use the old
> HTTP class in order to minimise the extent of this patch.  A simple and
> clear performance patch has in my experience a much greater chance of
> finding its way into the codebase than a more extensive rewrite :)
>
> You may have concerns regarding point 3 above, and I am open to
> suggestions.
>
> Now, what remains is the question of the read buffering for the socket
> fileobject.  Do you think that it is feasible to simply change the
> default read buffering for fileobjects to use buffering for readline()
> same as they do for read()?  Then we wouldn't need the second half of
> this patch and we could make a separate "socket" performance patch.
>
> Added file: http://bugs.python.org/file12127/xmlrpc.patch
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue4336>
> _______________________________________
> _______________________________________________
> Python-bugs-list mailing list
> Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/jeremy%40alum.mit.edu
>
>