On Thu, Sep 29, 2005, glyph@divmod.com wrote:
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.
My understanding of the original purpose of the split -- which is probably wrong -- though was to allow parts of twisted to release without massive dependencies on near unrelated release critical bugs, and further to allow users of multiple bits of Twisted to not have to upgrade them all as a lump. If we have a model where an enormous group of request-response protocols are lumped with web, we return to the following release management problems: 1. rapidly evolving code, like FTP, which seems to have some parts working now and were it an independent project should probably be having some highly alpha releases, will not be released until it is sufficiently stable to be bundled with a more used and mature protocol like HTTP, and may in turn block said releases by being highly alpha. 2. relatively unrelated code, like ftp, or the hypotheticals above, will need to go unreleased every time there is a major years-long rewrite of a large component (web2) My understanding of the release-early-release-often philosophy was to encourage early adopting users (who are also more likely to become contributors). As it is, no sub-project is releasing and core looks set for a pretty slow ongoing release cycle. I may be naive about this, but my concern is that while core has critical mass in terms of users, the protocols and applications largely don't, and won't until they are seen by potential users to be active and supported, part of which is actually releasing. Having users in turn has been known to spur development. What you're proposing sounds like a mature release policy: as in, sub-projects will be rather monolithic and will release when they're mature. Is this correct, and if so, will they release? -Mary