Goals of a split:
* 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. ;)
* 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.
* 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.
Concerns of a split:
* 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)
Not Concerns of a split:
* Backwards compatibility. I'm ok with breaking old applications built on twisted.web. I hope by simplifying the core we can expand the possibilities for later development. I've changed my mind about turning Nevow into twisted.web2. I think that would just cause more problems down the line. I want to make twisted.web the simplest webserver it can be without sucking.
Distrib and Vhost Specifics:
Currently distrib really gets caught up handling some of the complex objects that are used in the nevow.appserver.NevowRequest object.
It first throws an InsecureJelly exception when it hits a nevow.context.WovenContext. If you shoehorn that by making it a pb.Copyable with a None returning getStateForCopy method it immediately throws an exception for nevow.appserver.OldResourceAdapter. When you shoehorn that through with the above method it throws an InsecureJelly exception when it hits twisted.internet.defer.Deferred. Obviously you can see why i wouldn't want to pursue that methodology futher. It seems silly to have to do that just so stuff won't go over ther wire, I'm sure there is a simpler way but no one bothered to point it out to me when i was asking about it.
And NevowRequest seems like an ideal example of an object to complicated to bother with passing it through pb. Passing http.Request would be so much simpler and it would get us a little bit closer to realize this comment from twisted/web/distrib.py:
""" This is going to have to be refactored so that argument parsing is done by each subprocess and not by the main web server (i.e. GET, POST etc.). """
As I'm sure you've probably realized, I'm "That Guy Who Made Vhosts work in Nevow".
Yes that is me. And VHost wasn't such a big problem, but it got me thinking about how to do distrib and that led me to realize that perhaps they should not be implemented at what we currently think of as the Resource level, but instead at the Site level or even before that.
Both technologies need a minimal ammount of information to process the request. So it seems silly to have them handle server.Request and especially NevowRequest.
I guess I've sort of gone off on a rant there, and really wanted to avoid that. So I'll leave that as my opinion, and let you fine programmers comment.
The End.
These are just my first impressions about how a split should take place, I will admit to not being up on the core twisted.web code and certainly not on the core twisted. But i'm willing to put in the effort to learn it and take care of this if no one else is. Right now i make $6.75US/hr and go to school 2 days a week, i have probably as much free time as anyone else and I really really want this stuff to work.
-- David Reid
On Thu, 2004-04-15 at 06:47, David Reid wrote:
Not Concerns of a split:
- Backwards compatibility.
Just to clarify: you don't mean changing twisted.web to break backwards-compatibility, but instead mean that apps written for twisted.web will not always work with this new module. Correct?
I don't see a major problem with splitting code, as long as the old twisted.web and twisted.web.woven modules remain (so that people can continue to use applications that've already been written).
It's been pointed out before that twisted.web is an app server, not a protocol implementation, and thus there is justification for moving it outside of Twisted. What do the gurus think?
Right now I make $6.75US/hr and go to school 2 days a week, i have probably as much free time as anyone else and I really really want this stuff to work.
I'm graduating in a month, with no job, so I may have a hell of a lot of time to spend on this soon. :)
It's been pointed out before that twisted.web is an app server, not a protocol implementation, and thus there is justification for moving it outside of Twisted. What do the gurus think?
I will risk a modest outsider point of view - I am /not/ a twisted guru but I hope this does not reduce the value of my opinion.
A large part of what makes twisted attractive is the ease of implementation of services with it. Removing woven/nevow from twisted does not look like a good idea to me. It would mean that creating web services around twisted will become harder, which is something twisted is really good at.
Twisted is the best "glue" framework I have ever seen (it allow us to integrate LDAP, web, XMLRPC - and other things together in a /coherent/ manner.
It allowed us to develop our internal tools not like a patch of etherogenous scripts but like something coherent, easy to maintain and improve as nearly everything we needed was already there.
To provide you some background, our web server is currently implemented using woven - so my opinion may be biased but we are planning to port our code to Nevow when/if it is integrated. Having the code of Nevow/Woven in the twisted tree mean that people using it are sure that it is kept in sync by the automatic build test and I think it is important that it stays here.
Now should you think that the old code should be replaced, I would suggest that you leave the current web code here, for people like me using it, but create a new www section (or whatever name)
For information, the reason I decided for twisted over other technology was: * python as development language * The quality of the framework in general * number of protocol already available * ease of integration of in house tools with the "built-in" webserver
As well, it meant that I could make sure that the time investment in learning twisted will be justified by it wide usage.
The only thing we missed was a radius library so we had to code our radius server from pyrad ... If we get around to clean it, I will make sure we submit it.
Hope it was not too much out of topic. I sincerely think that twisted is the best thing which happened to python since the birth of Guido, so keep on the good work.
Regards,
Thomas
Thomas Mangin wrote:
A large part of what makes twisted attractive is the ease of implementation of services with it. Removing woven/nevow from twisted does not look like a good idea to me. It would mean that creating web services around twisted will become harder, which is something twisted is really good at.
Well, it's pretty much already decided to do this. But hopefully I'll be able to explain why this isn't a bad thing.
Twisted is the best "glue" framework I have ever seen (it allow us to integrate LDAP, web, XMLRPC - and other things together in a /coherent/ manner.
Heh heh -- LDAP support isn't in Twisted proper (Ldaptor is a third party package). You still cite it as coherent with the framework! This is proof that your worrying about coherency isn't justified.
It allowed us to develop our internal tools not like a patch of etherogenous scripts but like something coherent, easy to maintain and improve as nearly everything we needed was already there.
Twisted is currently very hard to maintain, for us. For *you*, the only change is that you'll have to 'apt-get install twisted-web' as well as 'apt-get install twisted'. :-)
To provide you some background, our web server is currently implemented using woven - so my opinion may be biased but we are planning to port our code to Nevow when/if it is integrated. Having the code of Nevow/Woven in the twisted tree mean that people using it are sure that it is kept in sync by the automatic build test and I think it is important that it stays here.
Nevow is definitely never going to be integrated with Twisted.
Now should you think that the old code should be replaced, I would suggest that you leave the current web code here, for people like me using it, but create a new www section (or whatever name)
Yeah, we'll probably leave the existing stuff in Twisted for a while, with a deprecation warning to use the new packages.
...
Anyway, I think you're overreacting; the coherency of the quality and integration of Twisted projects is not going to be lessened by this breakup (we're breaking out a lot more than twisted-web: conch, flow, lore, protocols, they're all being split up).
These will still be Twisted "official" projects. They will still be coherent. The reason we're doing this is to make maintaining and releasing easier. Twisted is just too huge and has too many parts of differing stability to make it practical to keep it together.
Christopher Armstrong wrote:
Thomas Mangin wrote:
A large part of what makes twisted attractive is the ease of implementation of services with it. Removing woven/nevow from twisted does not look like a good idea to me. It would mean that creating web services around twisted will become harder, which is something twisted is really good at.
These will still be Twisted "official" projects. They will still be coherent. The reason we're doing this is to make maintaining and releasing easier. Twisted is just too huge and has too many parts of differing stability to make it practical to keep it together.
Well, it's pretty much already decided to do this. But hopefully I'll be able to explain why this isn't a bad thing.
You did thank you.
Heh heh -- LDAP support isn't in Twisted proper (Ldaptor is a third party package). You still cite it as coherent with the framework! This is proof that your worrying about coherency isn't justified.
Could not have provided you with a better argument if I had been looking for one ;-)
Twisted is currently very hard to maintain, for us. For *you*, the only change is that you'll have to 'apt-get install twisted-web' as well as 'apt-get install twisted'. :-) [...] Anyway, I think you're overreacting; the coherency of the quality and integration of Twisted projects is not going to be lessened by this breakup (we're breaking out a lot more than twisted-web: conch, flow, lore, protocols, they're all being split up).
Sorry if I looked that way ;-) I am not. I just did not realised what you were really wanting to do, I should folllow the list more closely but time is missing me.
Thomas
On Thu, 2004-04-15 at 09:37, Thomas Mangin wrote:
It's been pointed out before that twisted.web is an app server, not a protocol implementation, and thus there is justification for moving it outside of Twisted. What do the gurus think?
I will risk a modest outsider point of view - I am /not/ a twisted guru but I hope this does not reduce the value of my opinion.
I'm not a twisted guru either, but after trying to shoehorn distrib into Nevow i've come to the conclusion that a split of all 3 technologoies (framework, webserver and complex magical rendering engine) should happen sooner rather than later, and everyone who currently Knows Enough (TM) to do it is busy on other things, so I'm taking the proverbial bull by the horns and trying to get it done.
Integration of Nevow into twisted-web is a bad idea in my opinion for reasons I've mentioned in previous emails (see my reply to Alex Levy) So that probably won't happen unless someone can change my mind, and Nevow is definitely never going to be part of core twisted as radix pointed out.
David
I'm not a twisted guru either, but after trying to shoehorn distrib into Nevow i've come to the conclusion that a split of all 3 technologoies (framework, webserver and complex magical rendering engine) should happen sooner rather than later [...]
I was trying (and still trying) to say that I did believe that the web application part of twisted was important and should not be removed from the project. My "fear" were just unfounded and due to the fact that I only partially read the mailing list. I mis-understood the initial email.
Regards,
Thomas
On Thu, 2004-04-15 at 07:37, Alex Levy wrote:
On Thu, 2004-04-15 at 06:47, David Reid wrote:
Not Concerns of a split:
- Backwards compatibility.
Just to clarify: you don't mean changing twisted.web to break backwards-compatibility, but instead mean that apps written for twisted.web will not always work with this new module. Correct?
I do mean that the new twisted-web will NOT include woven, and things like distrib and vhosts will work differently. It will be written primarily to simply the usage of Nevow but keep the two seperate enough so that Nevow is not a dependency of twisted-web and that other style rendering engines (I guess that is what Nevow has become, far more than a templating engine, because it has changed how Requests act and how children are located and how pages are renderered.)
I don't see a major problem with splitting code, as long as the old twisted.web and twisted.web.woven modules remain (so that people can continue to use applications that've already been written).
The old modules will remain for a period with deprecation warnings, but this shouldn't be the responsibility of twisted-web. The people currently interested in this split seem to have never used woven, and never want to, so having to support it shouldn't be a responsibility.
It's been pointed out before that twisted.web is an app server, not a protocol implementation, and thus there is justification for moving it outside of Twisted. What do the gurus think?
twisted.web includes and appserver but also httpclient, which apprently isn't very good anyway. The twisted-web will be focused on being a useable and perhaps even efficient standalone webserver of static files and that can be easily handle integration with Nevow based applications.
Right now I make $6.75US/hr and go to school 2 days a week, i have probably as much free time as anyone else and I really really want this stuff to work.
I'm graduating in a month, with no job, so I may have a hell of a lot of time to spend on this soon. :)
good, maybe i'll just wait for you to do this ;)
Other notes. Part of the reason I'm pretty decided that t-web will NOT be built on Nevow but instead written to support Nevow is that I've seen twisted.web go from webwidgets, to domtemplate, to woven, and now to nevow, and I have absolutely no doubt that someone is going to come up with a newer, faster, better, stronger system in the future.
-- David Reid
David
The old modules will remain for a period with deprecation warnings, but this shouldn't be the responsibility of twisted-web. The people currently interested in this split seem to have never used woven, and never want to, so having to support it shouldn't be a responsibility.
Do you already have an idea of how long you are planning to keep the "legacy" T-web code in ? Do you foresee any clash between the old and new code or will someone be able to use both side by side. It would ease the transition.
Thomas
On Thu, 2004-04-15 at 11:27, Thomas Mangin wrote:
David
The old modules will remain for a period with deprecation warnings, but this shouldn't be the responsibility of twisted-web. The people currently interested in this split seem to have never used woven, and never want to, so having to support it shouldn't be a responsibility.
Do you already have an idea of how long you are planning to keep the "legacy" T-web code in ? Do you foresee any clash between the old and new code or will someone be able to use both side by side. It would ease the transition.
The "legacy" twisted.web is the responsibility of core twisted developers, it will probably be kept around until the new twisted-web system is alteast as useable as the current one, but probably not after the core twisted team modularizes the rest of twisted. And almost definitely not after foom finishes refactoring protocols.http with a new api.
On Thu, Apr 15, 2004, David Reid wrote:
The "legacy" twisted.web is the responsibility of core twisted developers, it will probably be kept around until the new twisted-web system is alteast as useable as the current one, but probably not after the core twisted team modularizes the rest of twisted. And almost definitely not after foom finishes refactoring protocols.http with a new api.
It would be good to define this with tests if you can (ie "when all these tests pass, core-Twisted-web will be no more").
-Mary
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.
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.
- 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.
James
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:
- finish rewriting http protocol
- fork t.web to a new dir
- 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
On Thu, Apr 15, 2004 at 11:57:13AM -0700, David Reid wrote:
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.
My thinking is this.
1) Generalise t.web so we have a simple API that we can plug an arbitary rendering engine onto.
2) Refactor all rendering engines so they confirm to a single API, so that one rendering engine can invoke another rendering engine without knowing anything about it.
3) Profit.
Stephen.
Stephen Thorne wrote:
On Thu, Apr 15, 2004 at 11:57:13AM -0700, David Reid wrote:
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.
My thinking is this.
- Generalise t.web so we have a simple API that we can plug an arbitary
rendering engine onto.
- Refactor all rendering engines so they confirm to a single API, so
that one rendering engine can invoke another rendering engine without knowing anything about it.
- Profit.
That's exactly what the twisted.web resource API does (in both twisted.web and nevow's fork of it).
On Thu, Apr 15, 2004 at 07:50:51PM -0400, Christopher Armstrong wrote:
My thinking is this.
- Generalise t.web so we have a simple API that we can plug an arbitary
rendering engine onto.
- Refactor all rendering engines so they confirm to a single API, so
that one rendering engine can invoke another rendering engine without knowing anything about it.
- Profit.
That's exactly what the twisted.web resource API does (in both twisted.web and nevow's fork of it).
We need to fix it up before goal 3 can be realised, because of the often noted problems of Request objects not being of the same class the same accross systems. The request is as important as the resource. This is the major component that needs refactoring.
Regards, Stephen Thorne.
Stephen Thorne wrote:
On Thu, Apr 15, 2004 at 07:50:51PM -0400, Christopher Armstrong wrote:
My thinking is this.
- Generalise t.web so we have a simple API that we can plug an arbitary
rendering engine onto.
- Refactor all rendering engines so they confirm to a single API, so
that one rendering engine can invoke another rendering engine without knowing anything about it.
- Profit.
That's exactly what the twisted.web resource API does (in both twisted.web and nevow's fork of it).
We need to fix it up before goal 3 can be realised, because of the often noted problems of Request objects not being of the same class the same accross systems. The request is as important as the resource. This is the major component that needs refactoring.
+10 on compatibility adapters for resource request.
On Thu, Apr 15, 2004, David Reid wrote:
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 take it this is a split along the lines of http://twistedmatrix.com/pipermail/twisted-python/2004-March/007345.html ? ie twisted.web will still be a "Twisted product" but will have its own release cycles and whatnot?
Can someone fill me in on whether this assumption is right? It has implications for both the content of the HOWTOs and their release cycle.
-Mary
Yes twisted-web ('-' no '.', probably tweb for module names, unless someone comes up with a better name) will still be a Twisted product, will have it's own release cycle, and own documentation.
-- David
On Fri, 2004-04-16 at 18:50, Mary Gardiner wrote:
On Thu, Apr 15, 2004, David Reid wrote:
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 take it this is a split along the lines of http://twistedmatrix.com/pipermail/twisted-python/2004-March/007345.html ? ie twisted.web will still be a "Twisted product" but will have its own release cycles and whatnot?
Can someone fill me in on whether this assumption is right? It has implications for both the content of the HOWTOs and their release cycle.
-Mary
Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
On Sat, Apr 17, 2004 at 04:06:50AM -0700, David Reid wrote:
Yes twisted-web ('-' no '.', probably tweb for module names, unless someone comes up with a better name) will still be a Twisted product, will have it's own release cycle, and own documentation.
It'd be really nice to have a good name for twisted-web++
Consider this a call for suggestions. Please present any names you think may be appropriate. If we don't find one, we'll just have to use 'tweb' or 'web' or something.
it'd be nice to follow the wonderful free-association schema that twisted has used in the past, jelly/banana, names, words, pair, trial, enterprise, cred, conch.
A suggestion I gave the other day was 'silk', but there's already a python-intarweb project that uses 'silk' in its naming, and its on sourceforge (with one developer and no files! but also registered in the last 60 days).
Regards, Stephen Thorne
Stephen Thorne wrote:
It'd be really nice to have a good name for twisted-web++
Consider this a call for suggestions. Please present any names you think may be appropriate. If we don't find one, we'll just have to use 'tweb' or 'web' or something.
it'd be nice to follow the wonderful free-association schema that twisted has used in the past, jelly/banana, names, words, pair, trial, enterprise, cred, conch.
I disagree. As a new user of twisted, I find the jelly/banana types of names annoying and confusing.
On Sat, Apr 17, 2004, David Reid wrote:
Yes twisted-web ('-' no '.', probably tweb for module names, unless someone comes up with a better name) will still be a Twisted product, will have it's own release cycle, and own documentation.
My understanding from this mail http://twistedmatrix.com/pipermail/twisted-python/2004-March/007355.html was that the HOWTOs were going to remain a single project. I take it this is no longer the case or that twisted-web/whatever is going to have its own documentation and be removed from the HOWTO?
-Mary
On Sat, Apr 17, 2004, Mary Gardiner wrote:
I take it this is no longer the case or that twisted-web/whatever is going to have its own documentation and be removed from the HOWTO?
Hmph, I feel like I'm negiotiating in bad faith, so I'll explain why I'm interested in the status of twisted-web docs.
At present, docs bugs tend to be assigned to me, and I have editorial control over the HOWTOs, in so far as anyone does. I'd be interesting in keeping twisted-web/whatever documentation as part of the Twisted HOWTO project, so my personal inclination is to argue against a doc split. Let me know what the pros are though.
It may be, as pointed out to me on IRC, that this is sufficiently early days that I'm wondering about things that don't really have answers yet. Maybe people will take their own docs and write them. Maybe not. I'll keep an eye out for answers when they appear :)
-Mary
In my previous email I meant they would (probably) be under the TwistedWeb tree and would probably be released as such, any future of a HOWTO section (perhaps these should be replaced by actual How-To do x y and z type docs) or a twisted-docs meta package I'm clueless about. But I feel it'd be best for each Twisted Products documentation to be part of said Twisted Product's tree if for no other reason than so the developers of said Twisted Product can atleast attempt to keep the Docs in sync with any api changes or cool new features.
I'm definitely for giving you full editorial control over any TwistedWeb docs, I sure don't want to do it. :)
--David
On Sat, 2004-04-17 at 04:49, Mary Gardiner wrote:
On Sat, Apr 17, 2004, Mary Gardiner wrote:
I take it this is no longer the case or that twisted-web/whatever is going to have its own documentation and be removed from the HOWTO?
Hmph, I feel like I'm negiotiating in bad faith, so I'll explain why I'm interested in the status of twisted-web docs.
At present, docs bugs tend to be assigned to me, and I have editorial control over the HOWTOs, in so far as anyone does. I'd be interesting in keeping twisted-web/whatever documentation as part of the Twisted HOWTO project, so my personal inclination is to argue against a doc split. Let me know what the pros are though.
It may be, as pointed out to me on IRC, that this is sufficiently early days that I'm wondering about things that don't really have answers yet. Maybe people will take their own docs and write them. Maybe not. I'll keep an eye out for answers when they appear :)
-Mary
Twisted-web mailing list Twisted-web@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
participants (8)
-
Alex Levy -
Christopher Armstrong -
David Reid -
Ed Suominen -
James Y Knight -
Mary Gardiner -
Stephen Thorne -
Thomas Mangin