On Thu, 29 Sep 2005 21:25:07 +1000, Andy Gayton <andy@thecablelounge.com> wrote:
I'll have another shot at this :)
Jp Calderone wrote:
* web2 is unreleased
I also object to the dependency, although I would propose the opposite solution: I don't think that "twisted.vfs" makes *any* sense as a separate project. web2 should not be a trivial HTTP server with a small resource wrapper in it. It should be a full-featured web server. Web does not mean "http" - all web-related protocols, such as WebDAV, ftp, even SOAP or Gopher, should be part of the 'web server' product part of Twisted. Going forward, I will stipulate this requirement: each independent Twisted subpackage MUST be at least 2 things: a functioning infrastructure layer that can be used by 3rd party applications, and an application which can be used standalone or with application plugins. In twisted.web's case this application is a "web server", which primarily does HTTP but can provide other request/response based protocols as well. "application plugins" for the web server are things that respond to requests for particular URLs. This requirement does imply the removal of a few existing Twisted packages. twisted.xish and twisted.flow come to mind. While I don't think that anything is actually using twisted.flow at this point, xish's useful code should move into the package that actually makes use of it (twisted.words.jabber). twisted.pair should probably just be part of eunuchs; while Twisted applications can use it, it certainly doesn't seem to stand on its own. I don't think it's important to act particularly quickly since I don't think any of these packages are seeing widespread external usage, but I definitely don't want to create more packages in this situation. While Twisted packages may not depend on external projects (NO MORE NEVOW IMPORTS ANYWHERE, PLEASE), it is reasonable to have soft internal dependencies; such as web2 including a Conch plugin (importing Conch interfaces) that provides an HTTP/Gopher/etc backend for SFTP. These dependencies can also be circular, so long as the circularity is between packages and not modules, AND the imports happen after startup; for example, it would also be reasonable for the previous scenario to co-exist with a plugin distributed with conch to enable SFTP servers to be used as web resources.