[Twisted-web] Splitting twisted-web from core twisted.

[David Reid]

On Thu, 2004-04-15 at 11:29, James Y Knight wrote:
> 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 
> > seperate
> > module.  Also given fzZzy's history it seems very likely that 
> > eventually
> > he will come up with something even better than Nevow, and it would 
> > just
> > 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 
> completely.

Yes that was my thinking also, because supporting modular rendering
engines is useless unless you provide a default that makes the system
generally useable.

> 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.
> 5) ??
> 
> 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.

I guess that's me!

I assume protocols.http's refactored state will remain in the core
twisted?  It would seem silly not to, and it also seems silly to do
major refactorying without having someone prepared to port twisted-web
to the new api.  So I'm volunteering, but I might need a lot of help
along the way.

> > * 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 
> > to
> > 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.

Of course not, I didn't intend to imply that it was, a code fork in the
technical sense is necessary, I did not want to fork the project in a
political sense.

--David