[Twisted-web] Splitting twisted-web from core twisted.
James Y Knight
foom at fuhm.net
Thu Apr 15 12:29:44 MDT 2004
On Apr 15, 2004, at 6:47 AM, David Reid wrote:
> Goals of a split:
> * Use new APIs.
> This is as good a chance as any to get rid of all those
> DeprecationWarnings we get when starting a twisted.web server.
I'm currently working on rewriting protocols.http. The goal is to
actually be RFC compliant, with enough builtin functionality to make
writing a server, client, and proxy on top of it fairly easy. I don't
plan on keeping API compatibility, although there's some chance a
wrapper implementing the old API could be made.
> * Implement things like distrib and vhosts at a lower level.
> Currently distrib and vhosts need to be reimplemented or atleast
> violently shoehorned into working with Nevow. This will likely be the
> same with any future alternatives to Nevow. I'll get into specifics
> about distrib and vhosts later.
Agreed. I think web should *not* be serializing Request objects at all.
Distrib is essentially just a non-caching proxy and could be
implemented more like one. (E.g. use a custom HTTPChannel that talks
over PB and doesn't require multiple sockets, but otherwise has just
normal HTTP string data being sent back and forth). This would have the
advantage of decoupling the distrib'd servers from any changes.
> * Simplify the twisted.web, don't make it do anything clever.
> The clever stuff should be left up to nevow and perhaps kept a
> module. Also given fzZzy's history it seems very likely that
> he will come up with something even better than Nevow, and it would
> be a waste to have to rewrite twisted.web (again) to support it. ;)
Sure, nevow (the templating part only) can be in a separate module
(newtwistedweb.nevow, say), but I'm not sure it's good to separate them
What I think needs to happen:
1) finish rewriting http protocol
2) fork t.web to a new dir
3) Remove crap: woven, monitor, html, dom*, google, trp, widgets, wmvc,
4) Merge nevow's appserver, request, static, dirlist, ... change back,
and modify for the new http API.
As I'm not the only person interested (yay!), someone else could be
working on 2-4 while I'm getting 1 to a good enough state that "modify
to new API" part can happen.
> * Failing.
> I don't want to fork the code, I want to officially split twisted.web
> from core twisted and refactor it to support the above goals. I need
> know this is what people want to happen, and I need input to make sure
> it's done Reasonably Right (TM)
I think this is what people want to do. We *will* need to fork for a
while, until a proper mostly-stable release happens, but it shouldn't
need to be forever. Deprecating twisted.web before a replacement has
happened isn't really possible.
More information about the Twisted-web