Re: [stdlib-sig] Any feedback on proposed http and xmlrpc packages?
On Feb 3, 2008 9:06 PM, Bill Janssen <janssen@parc.com> wrote:
I'm good with the proposed HTTP re-org, but I think the XML-RPC classes should also go into the "http." package (http.tools or http.server as appropriate) -- there's nothing magical about XML-RPC.
Well, it's an RPC protocol, not something specific to HTTP. It might use HTTP as its transport agent, but that's its only connection. When I think "XML-RPC", I don't automatically think, "I should look in the HTTP section of the standard library". I think either XML-RPC or RPC protocols.
Maybe a subpackage, "http.xmlrpc".
Problem with that is Guido said he wants any renaming to make the name as simple if not simpler. Sticking XML-RPC libraries into http does not do that. Plus there is a general agreement that these new packages will only be one level deep.
I also think putting server classes into "http.server", but putting the client-side code, httplib, into "http.tools", is a bit lopsided. True, httplib is a mix of client-side and general utility functions, but still... But that's a minor nit. On the other hand, if we're going to mess around with the locations, might as well get it right the first time.
Sure, but what is right? The reason it has taken this long and led to the creation of a separate mailing list is because everyone's "right" is different. We are going to end up with a better solution, but there is not right solution. -Brett
Well, it's an RPC protocol, not something specific to HTTP. It might use HTTP as its transport agent, but that's its only connection.
Huh? That's its main distinction -- it uses (badly) a buggy slow inefficient but perceived-to-be-easy-to-implement RPC subsystem, HTTP. I guess I'm just looking at it from the perspective of an RPC guy.
Sure, but what is right? The reason it has taken this long and led to the creation of a separate mailing list is because everyone's "right" is different. We are going to end up with a better solution, but there is not right solution.
Actually, two different separate mailing lists.
We are going to end up with a better solution, but there is not right solution.
It has to be enough better to be worth doing. I'm not sure we're there yet, and just trying to help us get there. Bill
participants (2)
-
Bill Janssen
-
Brett Cannon