fork to Nevow documentation
Hi. I have forked the Nevow documentation: http://svn.python.it/twisted/trunk/contrib/nevow/doc/ Since I'm using Nevow for a project, I will try to document as many things as I can. Manlio Perillo
Dnia Wednesday 19 July 2006 12:00, Manlio Perillo napisał:
I have forked the Nevow documentation: http://svn.python.it/twisted/trunk/contrib/nevow/doc/
Why are you forking it? Any particular reasons you don't want to fix things in the mainstream? -- Michal Pasternak
Michal Pasternak ha scritto:
Dnia Wednesday 19 July 2006 12:00, Manlio Perillo napisał:
I have forked the Nevow documentation: http://svn.python.it/twisted/trunk/contrib/nevow/doc/
Why are you forking it? Any particular reasons you don't want to fix things in the mainstream?
For my convenience, of course! Since I'm using Nevow for a project, I want to annotate all things that I'm going to learn. Regards Manlio Perillo
On Thu, 20 Jul 2006 15:33:09 -0200, Manlio Perillo
Michal Pasternak ha scritto:
Dnia Wednesday 19 July 2006 12:00, Manlio Perillo napisał:
I have forked the Nevow documentation: http://svn.python.it/twisted/trunk/contrib/nevow/doc/
Why are you forking it? Any particular reasons you don't want to fix things in the mainstream?
For my convenience, of course! Since I'm using Nevow for a project, I want to annotate all things that I'm going to learn.
You don't need to fork Nevow's documentation to do this. Forking just makes it extremely unlikely that any improvements you make will ever be re-incorporated into Nevow. This is detrimental to the community in numerous ways. It can discourage improvements to Nevow's documentation, it can confuse people trying to learn Nevow, and it makes it less likely that people who do know Nevow well will offer criticism of what you write or point out flaws in your understanding. I hope that you will consider offering patches and other contributions directly to Nevow's documentation instead of maintaining a complete fork of it. Jean-Paul
Jean-Paul Calderone ha scritto:
You don't need to fork Nevow's documentation to do this. Forking just makes it extremely unlikely that any improvements you make will ever be re-incorporated into Nevow. This is detrimental to the community in numerous ways. It can discourage improvements to Nevow's documentation, it can confuse people trying to learn Nevow, and it makes it less likely that people who do know Nevow well will offer criticism of what you write or point out flaws in your understanding.
I hope that you will consider offering patches and other contributions directly to Nevow's documentation instead of maintaining a complete fork of it.
Please consider that this is a "private" fork. I can write a complete new tutorial but I prefer to expand the current documentation. Once the work is done, I will submit the patches for the ufficial documentation. I hope I can document all aspects of Nevow needed for a complete app, and I need a central repository for possible feedbacks. Regards Manlio Perillo
On Thu, 20 Jul 2006 16:25:00 -0200, Manlio Perillo
Jean-Paul Calderone ha scritto:
You don't need to fork Nevow's documentation to do this. Forking just makes it extremely unlikely that any improvements you make will ever be re-incorporated into Nevow. This is detrimental to the community in numerous ways. It can discourage improvements to Nevow's documentation, it can confuse people trying to learn Nevow, and it makes it less likely that people who do know Nevow well will offer criticism of what you write or point out flaws in your understanding.
I hope that you will consider offering patches and other contributions directly to Nevow's documentation instead of maintaining a complete fork of it.
Please consider that this is a "private" fork. I can write a complete new tutorial but I prefer to expand the current documentation.
Once the work is done, I will submit the patches for the ufficial documentation.
I hope I can document all aspects of Nevow needed for a complete app, and I need a central repository for possible feedbacks.
You are welcome to commit access to the Nevow repository. Jean-Paul
Jean-Paul Calderone ha scritto:
[...]
I hope I can document all aspects of Nevow needed for a complete app, and I need a central repository for possible feedbacks.
You are welcome to commit access to the Nevow repository.
Thanks but I don't want it, not now. The reason is http://svn.python.it/twisted/trunk/contrib/nevow/doc/txt/nevow-sessions.txt It is by no way a complete and good documentation! It needs a lot of feedback, but using only the mailing list for discussion is no good. Moreover I still have to use sessions in my application, so I can not test a real working application; for now it is like a placeholder. Regards Manlio Perillo
Dnia Thursday 20 July 2006 22:59, Manlio Perillo napisał:
Jean-Paul Calderone ha scritto:
[...]
I hope I can document all aspects of Nevow needed for a complete app, and I need a central repository for possible feedbacks.
You are welcome to commit access to the Nevow repository.
Thanks but I don't want it, not now.
I think, that this is not too wise, Manilo. More people can cooperate on the documentation with you when you use official Nevow repository, no matter if they're reading the list or not. TC, -- Michal Pasternak
On Thu, 20 Jul 2006 18:59:32 -0200, Manlio Perillo
It is by no way a complete and good documentation! It needs a lot of feedback, but using only the mailing list for discussion is no good.
I disagree. The mailing list instead is a good place to have the feedback and the bugtracker is a good place for patches. IMHO that session document is not very good :/. The reason is the fact that it uses the session to store information. While this is not especially bad it has a drawback. It stores state in something that is not persistent nor shared between the servers that might exist in your farm. User data or preferences or whatever should be stored in the database or in another persistent mechanism. All unless you use a stateful loadbalancer which would allow to store stuff in the session (although that wouldn't still work with persistent sessions).
Moreover I still have to use sessions in my application, so I can not test a real working application; for now it is like a placeholder.
Sessions are actually only an implementation detail of the web and shouldn't be exposed in any way to the developer or the user. I say shouldn't because there might be usecases where it is actually needed although the general case should even come close to know that there are sessions. Imho at least.
Valentino Volonghi aka Dialtone ha scritto:
On Thu, 20 Jul 2006 18:59:32 -0200, Manlio Perillo
wrote: It is by no way a complete and good documentation! It needs a lot of feedback, but using only the mailing list for discussion is no good.
I disagree. The mailing list instead is a good place to have the feedback and the bugtracker is a good place for patches.
Maybe I should make this more clear! For now this documents I'm writing are only: - placeholders - containers for put in everything I found on the archive of this mailing list - containers for put in my doubts So, I think that this, for now, should have nothing to do with the standard documentation.
IMHO that session document is not very good :/. The reason is the fact that it uses the session to store information.
While this is not especially bad it has a drawback. It stores state in something that is not persistent nor shared between the servers that might exist in your farm.
Yes, this should be explained in the document, thanks.
User data or preferences or whatever should be stored in the database or in another persistent mechanism.
Of course! For now I simply want to describe how to use Twisted sessions.
All unless you use a stateful loadbalancer which would allow to store stuff in the session (although that wouldn't still work with persistent sessions).
Moreover I still have to use sessions in my application, so I can not test a real working application; for now it is like a placeholder.
Sessions are actually only an implementation detail of the web and shouldn't be exposed in any way to the developer or the user. I say shouldn't because there might be usecases where it is actually needed
As an example a counter on the number of failed logins.
although the general case should even come close to know that there are sessions.
I whould like to explain every thing, adding usecases and explaining benefits and problems. Regards Manlio Perillo
Manlio Perillo wrote:
Maybe I should make this more clear!
For now this documents I'm writing are only: - placeholders - containers for put in everything I found on the archive of this mailing list - containers for put in my doubts
So, I think that this, for now, should have nothing to do with the standard documentation.
If this was the case, why did you announce a fork? This seems to be your own personal thing with no immediate impact on the twisted community. Maybe I missed something... d
On 7/21/06, Duncan McGreggor
Manlio Perillo wrote:
Maybe I should make this more clear!
For now this documents I'm writing are only: - placeholders - containers for put in everything I found on the archive of this mailing list - containers for put in my doubts
So, I think that this, for now, should have nothing to do with the standard documentation.
If this was the case, why did you announce a fork? This seems to be your own personal thing with no immediate impact on the twisted community.
Maybe I missed something...
Sounds more like a sort of private branch of the repository, rather than a fork. Maybe it's just a terminology issue? Moof
participants (6)
-
Duncan McGreggor
-
Jean-Paul Calderone
-
Manlio Perillo
-
Michal Pasternak
-
Moof
-
Valentino Volonghi aka Dialtone