[RfC] Removal of old stuff in Zope 2.10
Hi, for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy: - ZopeTutorial (could be ripped off without implications and made available for download on zope.org) - HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers) - Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org. And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list). -aj
+1 on the lot if you are looking for votes. On Tue, 20 Dec 2005, Andreas Jung wrote:
Hi,
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
- ZopeTutorial (could be ripped off without implications and made available for download on zope.org)
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list).
-aj
--
On 12/20/05, Andreas Jung <lists@andreas-jung.com> wrote:
Hi,
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
- ZopeTutorial (could be ripped off without implications and made available for download on zope.org)
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list).
+0 on Gadfly, I have no opinion there. +1 on all else. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Tue, Dec 20, 2005 at 09:43:18AM +0100, Lennart Regebro wrote: | +0 on Gadfly, I have no opinion there. | +1 on all else. I have proposed using sqlite/ZSQLiteDA in the past which is more like a real database, but still embeded, but people didn't like much the idea. -- Sidnei da Silva Enfold Systems, LLC. http://enfoldsystems.com
+1 on all of them On Tue, December 20, 2005 07:52, Andreas Jung wrote:
Hi,
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
- ZopeTutorial (could be ripped off without implications and made available for download on zope.org)
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list).
-aj _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
_______________________________________________________________________
XLhost.de - eXperts in Linux hosting <<
Jürgen Herrmann Bruderwöhrdstraße 15b, DE-93051 Regensburg Fon: +49 (0)700 XLHOSTDE [0700 95467833] Fax: +49 (0)721 151 463027 WEB: http://www.XLhost.de
On 20 Dec 2005, at 06:52, Andreas Jung wrote:
Hi,
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
+1 on all of them. jens
+1 on all. On Dec 20, 2005, at 1:52 AM, Andreas Jung wrote:
Hi,
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
- ZopeTutorial (could be ripped off without implications and made available for download on zope.org)
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list).
-aj _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Andreas Jung wrote:
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
- ZopeTutorial (could be ripped off without implications and made available for download on zope.org)
+1
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
+0, it would be useful to not use the explanation texts that are in the help system, or at list check that other material (docstrings, zope book) are at least as comprehensive.
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
Gadfly should go, but OTOH have sqlite in its place would still provide SQL inside Zope and that could be a good plus.
And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list).
+1 as I don't use ZClasses and don't intend to maintain them. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
--On 20. Dezember 2005 14:05:26 +0100 Florent Guillaume <fg@nuxeo.com> wrote:
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
Gadfly should go, but OTOH have sqlite in its place would still provide SQL inside Zope and that could be a good plus.
This would require to move two more third-party packages into the Zope core (without having checked the licenses for the DA and the Python bindings). We discussed that issue already. Third party packages are a burden when the developers aren't active contributors to the Zope core. -aj
On Tue, Dec 20, 2005 at 07:52:02AM +0100, Andreas Jung wrote:
Hi,
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT??). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
- ZopeTutorial (could be ripped off without implications and made available for download on zope.org)
+1
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
-0 Whenever this topic comes up, people speak of HelpSys as if it's all API documentation for programmers. In fact the lion's share of it is user-oriented online structured text documentation which is IMNSHO very good to have. And many third-party products provide such documentation of their own. Especially when I was new to Zope, I read them constantly. +1 that the API docs should be extracted from interfaces and should leverage zope3 technology. See my old proposal here: http://www.zope.org/DevHome/Wikis/DevSite/Proposals/SanitizeHelpSysAndAPIRef... ... and the ensuing discussion: http://mail.zope.org/pipermail/zope-dev/2004-April/022226.html Status of that proposal: I did a large portion of step 1 and step 5 in the 2.7 version of the Zope Book, but - as Dieter predicted - I ran out of steam long before finishing it. It's a tedious job, and I only got small amounts of help from a couple of volunteers. -1 on removing the structured text docs. I don't know if anybody actually was proposing to remove it, but since nobody mentions it, it's easy to conclude that :-) All this stuff will take work... Maybe we could have a doc sprint at pycon?
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
+1
And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list).
+1 -- Paul Winkler http://www.slinkp.com
On Dec 20, 2005, at 10:36 AM, Paul Winkler wrote:
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
-0
Whenever this topic comes up, people speak of HelpSys as if it's all API documentation for programmers. In fact the lion's share of it is user-oriented online structured text documentation which is IMNSHO very good to have. And many third-party products provide such documentation of their own. Especially when I was new to Zope, I read them constantly.
In Zope 2.10 , Products packaged as Python Eggs will need either to drop support for helpsys stuff or the helpsys stuff will need to be revamped support files living in zipfiles. The former sounds saner to me and indeed Basket punts on registering help files for all egg- packaged products right now. I agree it would be helpful to have the info that's currently in the helpsystem for builtin Zope products be available somewhere else, though. - C
--On 20. Dezember 2005 12:27:41 -0500 Chris McDonough <chrism@plope.com> wrote:
In Zope 2.10 , Products packaged as Python Eggs will need either to drop support for helpsys stuff or the helpsys stuff will need to be revamped support files living in zipfiles. The former sounds saner to me and indeed Basket punts on registering help files for all egg- packaged products right now. I agree it would be helpful to have the info that's currently in the helpsystem for builtin Zope products be available somewhere else, though.
Speaking of eggs, could you please add this to the 2.10 wiki? :-) -aj
On Tue, Dec 20, 2005 at 12:27:41PM -0500, Chris McDonough wrote:
I agree it would be helpful to have the info that's currently in the helpsystem for builtin Zope products be available somewhere else, though.
I'm OK in principle with moving this stuff "somewhere else", and with properly deprecating context.registerHelp(), but we do need a replacement strategy, and I don't agree that we can simply drop support for help in third-party products. It's not just builtin products that are affected. I also think that keeping it online is a good thing. It's very convenient and you don't have to worry about e.g. linux distributions getting funny with where they decide to place things like bundled documentation files, or free/budget zope hosting plans where you may not even have ready access to the filesystem. Maybe if we don't want to bundle them, we could host them in a versioned hierarchy on zope.org, like the way old versions of Python docs are always available on python.org. Of course, that puts some pressure on zope.org to be up and responsive all the time... that's another topic ;-P btw, I don't think we should keep shoe-horning the API docs and online user docs into the same UI. It doesn't feel like a good fit in the current system. Maybe the current "Help!" link should point only to user docs, and there should be a separate link to the new Interface docs? -- Paul Winkler http://www.slinkp.com
On Tue, Dec 20, 2005 at 01:24:32PM -0500, Paul Winkler wrote:
Maybe if we don't want to bundle them, we could host them in a versioned hierarchy on zope.org, like the way old versions of Python docs are always available on python.org.
... which, duh, doesn't handle help for third-party products. So this is a non-solution. -- Paul Winkler http://www.slinkp.com
--On 20. Dezember 2005 13:32:02 -0500 Paul Winkler <pw_lists@slinkp.com> wrote:
On Tue, Dec 20, 2005 at 01:24:32PM -0500, Paul Winkler wrote:
Maybe if we don't want to bundle them, we could host them in a versioned hierarchy on zope.org, like the way old versions of Python docs are always available on python.org.
... which, duh, doesn't handle help for third-party products. So this is a non-solution.
I mentioned already Apidoc from Z3. One way would be to move the API descriptions of the Zope code into interface files (I don't know how much code in Zope has no interfaces so far...we could possibly autogenerate interface files from code). As far as I can see Apidoc in Z3 gets its information from the registered components and their interfaces. Possibly we could replace the registration of a product with the HelpSys with *some* registry which might be used by Apidoc (Apidoc looks very generic). *Possibly* we could register the STX file with this registry as well.... just-loud-thinking, -aj
On Tue, Dec 20, 2005 at 08:13:18PM +0100, Andreas Jung wrote:
--On 20. Dezember 2005 13:32:02 -0500 Paul Winkler <pw_lists@slinkp.com> wrote:
On Tue, Dec 20, 2005 at 01:24:32PM -0500, Paul Winkler wrote:
Maybe if we don't want to bundle them, we could host them in a versioned hierarchy on zope.org, like the way old versions of Python docs are always available on python.org.
... which, duh, doesn't handle help for third-party products. So this is a non-solution.
I mentioned already Apidoc from Z3.
OK, but as I keep saying, that only covers half of the problem.
One way would be to move the API descriptions of the Zope code into interface files (I don't know how much code in Zope has no interfaces so far...
I have no idea, but there are already quite a lot of z3 interfaces in zope 2.9.
As far as I can see Apidoc in Z3 gets its information from the registered components and their interfaces. Possibly we could replace the registration of a product with the HelpSys with *some* registry which might be used by Apidoc (Apidoc looks very generic). *Possibly* we could register the STX file with this registry as well....
ok... but as I said, I'm also wondering if help stx files should go in some parallel tree and not be mixed up with API docs at all. But maybe we could still leverage Apidoc for this tree somehow? I'm totally hand-waving here... just to be clear, the stuff I'm talking about is ZMI user interface docs, not programmer docs. -- Paul Winkler http://www.slinkp.com
--On 20. Dezember 2005 14:27:18 -0500 Paul Winkler <pw_lists@slinkp.com> wrote:
just to be clear, the stuff I'm talking about is ZMI user interface docs, not programmer docs.
I'll raise the question again: what are the benefits of the HelpSys for a Zope user? I just clicked through the HelpSys (I've never used and missed it throughout my Zope career) and all the unorganized information in the HelpSys are more or less in the same way available in the Zope Book (ZPT, DTML references etc.). The HelpSys presents the information just in an unusable and insane way...so I wonder what is the value of this crap? Would it hurt someone when we remove it? How many percent of the ppl using Zope - either through the ZMI or the filesystem - actually use this "information source" (it's more an information sink)? My theory: a) ppl never read documentation b) ppl read the Zope Book because we point them to the Zope Book as primary Zope resource. At least the Zope Book is somewhat maintained. The HelpSys docs were not update in the past as far as I can remember. My proposal would be: - forget the HelpSys forever - let's try to (auto)-generate interfaces from the existing code as the primary source for API related documentation - additional information and story telling should be done through doc tests - create an _optional_ replacement for HelpSys (Apidoc-based or whatever) -aj
On Tue, Dec 20, 2005 at 08:47:34PM +0100, Andreas Jung wrote:
--On 20. Dezember 2005 14:27:18 -0500 Paul Winkler <pw_lists@slinkp.com> wrote:
just to be clear, the stuff I'm talking about is ZMI user interface docs, not programmer docs.
I'll raise the question again: what are the benefits of the HelpSys for a Zope user? I just clicked through the HelpSys (I've never used and missed it throughout my Zope career) and all the unorganized information in the HelpSys are more or less in the same way available in the Zope Book (ZPT, DTML references etc.).
The big difference is that in many places in the ZMI, clicking "help" takes you to instructions *for the management page you are actually looking at*. Just because you and I have internalized all this information long ago does not mean it isn't useful to new users. I haven't looked at any of it recently because I don't need to anymore. But I remember when I *did* need to. The users affected most by this change are not going to be on zope-dev. Maybe I was a rare case and nobody else ever reads the help pages. I don't think we will find out by arguing about it here. Maybe a straw poll on the main zope list would teach us something? Something like "Did you, at some point while learning Zope, get anything useful from the help system?".
- additional information and story telling should be done through doc tests
For general "what is this / what does it do / how does it work" docs, I like that idea. But it doesn't help with filling out forms in the ZMI. Arguably, forms should be self-documenting, but the nice thing about a "help" link is that it doesn't distract you when you don't need it any more. -- Paul Winkler http://www.slinkp.com
--On 20. Dezember 2005 15:09:56 -0500 Paul Winkler <pw_lists@slinkp.com> wrote:
- additional information and story telling should be done through doc tests
For general "what is this / what does it do / how does it work" docs, I like that idea. But it doesn't help with filling out forms in the ZMI. Arguably, forms should be self-documenting, but the nice thing about a "help" link is that it doesn't distract you when you don't need it any more.
I've never met ppl who actually used the HelpSys so that's why I am raising the question about the value of the HelpSys. Lots of my co-workers work with Zope on different levels (scripters, product developers)...I've always pointed them to the Zope Book...the HelpSys was never a topic. -aj
Andreas Jung wrote:
I've never met ppl who actually used the HelpSys so that's why I am raising the question about the value of the HelpSys. Lots of my co-workers work with Zope on different levels (scripters, product developers)...I've always pointed them to the Zope Book...the HelpSys was never a topic.
I most commonly use the HurtSys for DateTime's api, and some of the idnexing apis. That said, I also agree it should die if something nicer comes along ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Andreas Jung wrote:
I've never met ppl who actually used the HelpSys so that's why I am raising the question about the value of the HelpSys. Lots of my co-workers work with Zope on different levels (scripters, product developers)...I've always pointed them to the Zope Book...the HelpSys was never a topic.
I most commonly use the HurtSys for DateTime's api, and some of the idnexing apis. That said, I also agree it should die if something nicer comes along ;-)
I use it a lot, and like Chris, for the DateTime stuff, but also for looking up how to manage properties, etc. It is/was a big help for me (more so than the zope book, at least when I was learning Zope) when learning stuff and looking up things. One difference I perceive (YMMV) between the Zope book and the Online help is that the online help is more of a renference than the Zope book. I think my point is that it is an added value if there is an online help available that does not require a live connection to the internet every time you need to look something up. So +1 on killing the current helpsystem and +1 on replacing it with something nicer :-) Sincerely, /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
Dario Lopez-Kästen wrote:
Chris Withers wrote:
Andreas Jung wrote:
I've never met ppl who actually used the HelpSys so that's why I am raising the question about the value of the HelpSys. Lots of my co-workers work with Zope on different levels (scripters, product developers)...I've always pointed them to the Zope Book...the HelpSys was never a topic.
I most commonly use the HurtSys for DateTime's api, and some of the idnexing apis. That said, I also agree it should die if something nicer comes along ;-)
I use it a lot, and like Chris, for the DateTime stuff, but also for looking up how to manage properties, etc. It is/was a big help for me (more so than the zope book, at least when I was learning Zope) when learning stuff and looking up things.
One difference I perceive (YMMV) between the Zope book and the Online help is that the online help is more of a renference than the Zope book.
I think my point is that it is an added value if there is an online help available that does not require a live connection to the internet every time you need to look something up.
So +1 on killing the current helpsystem and +1 on replacing it with something nicer :-)
The online help reference for ZPT is quite good (and DTML as well), and before I knew ZPT well I used it a lot. I still look there occasionally for minor API things (like property managers and DateTime), though obviously this is also at various web-based sources. DocFinderTab is generally superior, save for those objects and technologies that are not persistent objects, or are not described well by the API (ZPT and DateTime, for instance.) Also, I too use Gadfly frequently in training (and also when I was learning Zope), and it's fantastic that it's already there and usable. Installing MySQL or Postgres and an adapter is absurdly complicated with multiple people with multiple operating systems. I suppose a simple downloadable Product would be okay, but what burdens is that easing? --jcc -- "Building Websites with Plone" http://plonebook.packtpub.com
Dario Lopez-Kästen wrote:
Chris Withers wrote:
Andreas Jung wrote:
I've never met ppl who actually used the HelpSys so that's why I am raising the question about the value of the HelpSys. Lots of my co-workers work with Zope on different levels (scripters, product developers)...I've always pointed them to the Zope Book...the HelpSys was never a topic.
I most commonly use the HurtSys for DateTime's api, and some of the idnexing apis. That said, I also agree it should die if something nicer comes along ;-)
I use it a lot, and like Chris, for the DateTime stuff, but also for looking up how to manage properties, etc. It is/was a big help for me (more so than the zope book, at least when I was learning Zope) when learning stuff and looking up things.
One difference I perceive (YMMV) between the Zope book and the Online help is that the online help is more of a renference than the Zope book.
I think my point is that it is an added value if there is an online help available that does not require a live connection to the internet every time you need to look something up.
So +1 on killing the current helpsystem and +1 on replacing it with something nicer :-)
The online help reference for ZPT is quite good (and DTML as well), and before I knew ZPT well I used it a lot. I still look there occasionally for minor API things (like property managers and DateTime), though obviously this is also at various web-based sources. DocFinderTab is generally superior, save for those objects and technologies that are not persistent objects, or are not described well by the API (ZPT and DateTime, for instance.) Also, I too use Gadfly frequently in training (and also when I was learning Zope), and it's fantastic that it's already there and usable. Installing MySQL or Postgres and an adapter is absurdly complicated with multiple people with multiple operating systems. I suppose a simple downloadable Product would be okay, but what burdens is that easing? --jcc -- "Building Websites with Plone" http://plonebook.packtpub.com
On 20 Dec 2005, at 19:47, Andreas Jung wrote:
--On 20. Dezember 2005 14:27:18 -0500 Paul Winkler <pw_lists@slinkp.com> wrote:
just to be clear, the stuff I'm talking about is ZMI user interface docs, not programmer docs.
I'll raise the question again: what are the benefits of the HelpSys for a Zope user?
I would say the only benefit was the unification of docs for Zope and installed third party products in one place, and its "context- sensitivity" for documenting screens in the ZMI when you're on them by clicking the link. I've always tried to be good about it, and most of my software has relatively up-to-date HelpSys documentation. On the other hand I believe most product authors don't use HelpSys documentation, and the Zope-provided pieces are way less current and informative than the Zope book (2.7 version). IMHO it would be nice if the HelpSys could be changed so that it still provides those Help! links, but the product author can simply assign a URL to them to point to a place where they copied and pasted their docs into a website. That's not too much of an imposition on product authors I think. jens
On Tue, Dec 20, 2005 at 08:18:18PM +0000, Jens Vagelpohl wrote:
I would say the only benefit was the unification of docs for Zope and installed third party products in one place,
Good point!
and its "context- sensitivity" for documenting screens in the ZMI when you're on them by clicking the link. I've always tried to be good about it, and most of my software has relatively up-to-date HelpSys documentation.
Me too.
On the other hand I believe most product authors don't use HelpSys documentation, and the Zope-provided pieces are way less current and informative than the Zope book (2.7 version).
Yes. I think we as a community have a general documentation maintenance problem. It is something that neither ZC nor the community at large has placed sufficient value on - understandably! Free docs don't pay anybody's bills. There needs to be a driving force here stronger than "it would be nice to have better docs", or there never will be. Maybe once the Zope Foundation is up and running, I will propose that the Foundation play a role. Maybe fundraising and earmarking funds for doc work would help. (... oh crap, I forgot about the foundation chat today. Probably would have been OT at this stage anyway.)
IMHO it would be nice if the HelpSys could be changed so that it still provides those Help! links, but the product author can simply assign a URL to them to point to a place where they copied and pasted their docs into a website. That's not too much of an imposition on product authors I think.
I think that would work. If so, the question then becomes: timetable and plan for deprecating HelpSys. I don't think we can simply rip out registerHelp() in 2.10 unless we have deprecation warnings in 2.9; and a useful deprecation warning requires something in place we can advise people to do instead. -- Paul Winkler http://www.slinkp.com
On Dec 20, 2005, at 3:29 PM, Paul Winkler wrote:
If so, the question then becomes: timetable and plan for deprecating HelpSys. I don't think we can simply rip out registerHelp() in 2.10 unless we have deprecation warnings in 2.9; and a useful deprecation warning requires something in place we can advise people to do instead.
FWIW, I have zero plans to support a registerHelp that does anything but "pass" or "warn" for Egg products. If people think that isn't a reasonable thing to do, I may need to take my committment to integrating eggs off the table for 2.10 personally; of course others would be free to take the existing code and integrate. IOW, I intend to spend exactly zero brain cycles thinking about help system issues except to make it inoperable. ;-) - C
On Tue, Dec 20, 2005 at 03:58:05PM -0500, Chris McDonough wrote:
FWIW, I have zero plans to support a registerHelp that does anything but "pass" or "warn" for Egg products. If people think that isn't a reasonable thing to do, I may need to take my committment to integrating eggs off the table for 2.10 personally; of course others would be free to take the existing code and integrate. IOW, I intend to spend exactly zero brain cycles thinking about help system issues except to make it inoperable. ;-)
Hmm... Since eggs are a relatively new distribution mechanism, it doesn't make sense for basket (or whatever it evolves into) to waste effort on supporting old crap that's going away sooner or later. But I'm not sure I understand you. Are you saying that in order to use Basket, my product can't call registerHelp()? Or are you saying that when installed via Basket, registerHelp() does nothing? That's fine. -- Paul Winkler http://www.slinkp.com
On Dec 20, 2005, at 4:22 PM, Paul Winkler wrote:
But I'm not sure I understand you. Are you saying that in order to use Basket, my product can't call registerHelp()?
Or are you saying that when installed via Basket, registerHelp() does nothing? That's fine.
Yep, the latter currently...
--On 20. Dezember 2005 16:41:37 -0500 Chris McDonough <chrism@plope.com> wrote:
On Dec 20, 2005, at 4:22 PM, Paul Winkler wrote:
But I'm not sure I understand you. Are you saying that in order to use Basket, my product can't call registerHelp()?
Or are you saying that when installed via Basket, registerHelp() does nothing? That's fine.
Yep, the latter currently...
You could please describe what the implications between Basket and Helpys are? I would like to prototype something using Apidoc over the next days. But I need to know what the constraints are. -aj
On Dec 22, 2005, at 8:26 AM, Andreas Jung wrote:
--On 20. Dezember 2005 16:41:37 -0500 Chris McDonough <chrism@plope.com> wrote:
On Dec 20, 2005, at 4:22 PM, Paul Winkler wrote:
But I'm not sure I understand you. Are you saying that in order to use Basket, my product can't call registerHelp()?
Or are you saying that when installed via Basket, registerHelp() does nothing? That's fine.
Yep, the latter currently...
You could please describe what the implications between Basket and Helpys are?
Egg products may be run from a zipfile (this is a "distribution"; it might contain more than one product). Egg distributions can be marked as "non-zip-safe", in which case Basket will uncompress them to a cache directory before adding them to the "product path" (although the Products package namespace is not required for egg products). But the some products will be run entirely from a zipfile without decompressing them. Helpsys expects to be able to find help files on disk. pkg_resources is a module by Phillip Eby that can used to indirect file access through a separate API that makes it possible to read files from either a zipfile or from a directory path. Fred also wrote a package named zope.filereference which does the same. I suspect you may need to change apidoc to use one of these APIs when it's finding and reading files. - C
Jens Vagelpohl schrieb:
...
IMHO it would be nice if the HelpSys could be changed so that it still provides those Help! links, but the product author can simply assign a URL to them to point to a place where they copied and pasted their docs into a website. That's not too much of an imposition on product authors I think.
This was my first thought but then you have two problems: 1) online docs can be for new version while the user is for various reasons using older version - so the docs would not match either 2) privacy: this is the biggest issue - if someone clicks on the helpsys link (s)he transmits the url of the own ZMI via referrer (in 99% of all cases). This might be ok for zope.org, but I doubt this is ok for anybody elses website where who knows has access to the logs. I fear unless we play some ugly javascript games, there is no real way out of this. Maybe at least the url should be restricted to zope.org.
Andreas Jung wrote:
I'll raise the question again: what are the benefits of the HelpSys for a Zope user?
I can't recall clicking on top frame of the ZMI or a 'Help!' link in the past few years, either. Perhaps an equivalent or greater benefit would be to rip out locally installed static help facilities, and spend the effort migrating* zope.org to a plone version that could run PloneHelpCenter: http://plone.org/documentation * or a clean-slate docs.zope.org, just as well.
Jeff Kowalczyk wrote:
Andreas Jung wrote:
I'll raise the question again: what are the benefits of the HelpSys for a Zope user?
I can't recall clicking on top frame of the ZMI or a 'Help!' link in the past few years, either. Perhaps an equivalent or greater benefit would be to rip out locally installed static help facilities, and spend the effort migrating* zope.org to a plone version that could run PloneHelpCenter:
FWIW, I think storing docs anywhere on the filesystem and in the product distribution is absolutely 100% evil. You asking product authors to commit to a url being around forever, and that's unreasonable and foolish... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
Formulator's using this and I think it might be used by some people. I'm okay with trying to switch Formulator on to something like apidoc though. Regards, Martijn
Andreas Jung wrote:
Hi,
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
-1 From time to time I teach classes on Zope. Often to people with an sql legacy. Most companies don't have a computer lab with similar machines, so often the educational software must be installed on the participants own machine. Which can be of any platform. Using Gadfly as an educational tool is *very* practical. Eg. they can install Zope, and begin using sql at once. Having to install postgres etc. just to teach about database connections etc. would be really impractical. If there is another practical way to do it, that would be fine too. I don't know about sqllite. But if it's more difficulte than dropping a package into a directory it would be bad. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
--On 21. Dezember 2005 17:10:19 +0100 Max M <maxm@mxm.dk> wrote:
If there is another practical way to do it, that would be fine too. I don't know about sqllite. But if it's more difficulte than dropping a package into a directory it would be bad.
I mentioned to make it available as download. So you can install it when needed. -aj
Max M wrote:
If there is another practical way to do it, that would be fine too. I don't know about sqllite. But if it's more difficulte than dropping a package into a directory it would be bad.
Personally I'd be a huge proponent of including SQLite in zope core. It is extraordinarilly functional and has few requirements. I particularly like using it to ensure unit tests against RDBMS connections work properly. Requiring a user to install postgresql just to run the unit tests of a product is somewhat unfeasible. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net
--On 21. Dezember 2005 17:23:26 -0330 Rocky Burt <rocky@serverzen.com> wrote:
Personally I'd be a huge proponent of including SQLite in zope core. It is extraordinarilly functional and has few requirements. I particularly like using it to ensure unit tests against RDBMS connections work properly. Requiring a user to install postgresql just to run the unit tests of a product is somewhat unfeasible.
Do you volunteer to take over the responsibility for this project? That means: - integrate the python bindings - integrate the DA - if necessary update existing documentation - convince someone from ZC to import the Sqlite code base on svn.zope.org (since Sqlite is _not_ ZPL only a ZC employee is permitted to import non-ZPL code). -aj
Rocky Burt wrote:
Max M wrote:
If there is another practical way to do it, that would be fine too. I don't know about sqllite. But if it's more difficulte than dropping a package into a directory it would be bad.
Personally I'd be a huge proponent of including SQLite in zope core. It is extraordinarilly functional and has few requirements. I particularly like using it to ensure unit tests against RDBMS connections work properly. Requiring a user to install postgresql just to run the unit tests of a product is somewhat unfeasible.
- Rocky
I would like that. Whenever giving a Zope/Plone class I end up using gadfly since this is the only db every one attending can use. As gadfly is very limited, it would be great to have something a bit more powerful. I would like to help making this possible. Robert
robert rottermann schrieb:
Rocky Burt wrote:
Max M wrote:
If there is another practical way to do it, that would be fine too. I don't know about sqllite. But if it's more difficulte than dropping a package into a directory it would be bad.
Personally I'd be a huge proponent of including SQLite in zope core. It is extraordinarilly functional and has few requirements. I particularly like using it to ensure unit tests against RDBMS connections work properly. Requiring a user to install postgresql just to run the unit tests of a product is somewhat unfeasible.
I dont think we should inlcude more 3rd party products into zope core unless they are required for core funtionality. And a random database adaptor isnt really core functionality. Linking interesting products from the download-page could be improved to fill the gap imho. Regards Tino
--On 22. Dezember 2005 12:32:07 +0100 Tino Wildenhain <tino@wildenhain.de> wrote:
I dont think we should inlcude more 3rd party products into zope core unless they are required for core funtionality. And a random database adaptor isnt really core functionality.
Another point: with Zope 2.10 we want to replace more and more duplicate code from the Zope 2 core with Zope 3 code. Since out-of-the-box RDBMS functionality might be off interest for the Zope 3 community it should be part of the Zope 3 (to be re-used within Zope 2). I think that would be the way to go if there is consensus about the necessity for having Sqlite in Zope 2/3 (the license issue is still an open point). -aj
Andreas Jung wrote:
--On 22. Dezember 2005 12:32:07 +0100 Tino Wildenhain <tino@wildenhain.de> wrote:
I dont think we should inlcude more 3rd party products into zope core unless they are required for core funtionality. And a random database adaptor isnt really core functionality.
Another point: with Zope 2.10 we want to replace more and more duplicate code from the Zope 2 core with Zope 3 code. Since out-of-the-box RDBMS functionality might be off interest for the Zope 3 community it should be part of the Zope 3 (to be re-used within Zope 2). I think that would be the way to go if there is consensus about the necessity for having Sqlite in Zope 2/3 (the license issue is still an open point).
-aj
I perfectly agree with both of these arguments. However having a "dead easy to use" RDBMS tool is very convenient. Both for teaching and marketing purposes. Robert
--On 22. Dezember 2005 15:20:27 +0100 robert rottermann <robert@redcor.ch> wrote:
I perfectly agree with both of these arguments. However having a "dead easy to use" RDBMS tool is very convenient. Both for teaching and marketing purposes.
I agree (meanwhile) but we have to sort out the issues I mentioned already (license, integration with Z 3, who volunteers :-)) -aj
Andreas Jung wrote:
--On 22. Dezember 2005 15:20:27 +0100 robert rottermann <robert@redcor.ch> wrote:
I perfectly agree with both of these arguments. However having a "dead easy to use" RDBMS tool is very convenient. Both for teaching and marketing purposes.
I agree (meanwhile) but we have to sort out the issues I mentioned already (license, integration with Z 3, who volunteers :-))
Hmm... I'm definitely willing to help out here. But one strike against me is my lack of zope3 development knowledge. When you mentioned before about importing sqlite into svn.zope.org, you were talking about actually including a snapshot of sqlite inside zope source rather than making it a build time requirement? - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net
--On 22. Dezember 2005 11:42:30 -0330 Rocky Burt <rocky@serverzen.com> wrote:
When you mentioned before about importing sqlite into svn.zope.org, you were talking about actually including a snapshot of sqlite inside zope source rather than making it a build time requirement?
I really don't care about how to do it..this would be up to the volunteer. But the license issue must be discussed since you are not allowed to import non-ZPL code to svn.zope.org. -aj
Andreas Jung wrote:
--On 22. Dezember 2005 11:42:30 -0330 Rocky Burt <rocky@serverzen.com> wrote:
When you mentioned before about importing sqlite into svn.zope.org, you were talking about actually including a snapshot of sqlite inside zope source rather than making it a build time requirement?
I really don't care about how to do it..this would be up to the volunteer. But the license issue must be discussed since you are not allowed to import non-ZPL code to svn.zope.org.
Well, if we simply suck sqlite in as a build time requirement (during the 'make' process) do we care about importing non-ZPL code into svn.zope.org? We would only care about licensing when distributing binaries that include sqlite, no? - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net
sqlite is public domain code, FWIW. I doubt this is incompatible with the ZPL. It would just require an acknowledgement from ZC that it's "safe" to be included in a Zope distro. - C On Dec 22, 2005, at 11:14 AM, Rocky Burt wrote:
Andreas Jung wrote:
--On 22. Dezember 2005 11:42:30 -0330 Rocky Burt <rocky@serverzen.com> wrote:
When you mentioned before about importing sqlite into svn.zope.org, you were talking about actually including a snapshot of sqlite inside zope source rather than making it a build time requirement?
I really don't care about how to do it..this would be up to the volunteer. But the license issue must be discussed since you are not allowed to import non-ZPL code to svn.zope.org.
Well, if we simply suck sqlite in as a build time requirement (during the 'make' process) do we care about importing non-ZPL code into svn.zope.org? We would only care about licensing when distributing binaries that include sqlite, no?
- Rocky
-- Rocky Burt ServerZen Software -- http://www.serverzen.com ServerZen Hosting -- http://www.serverzenhosting.net News About The Server -- http://www.serverzen.net
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Rocky Burt wrote:
Well, if we simply suck sqlite in as a build time requirement (during the 'make' process) do we care about importing non-ZPL code into svn.zope.org? We would only care about licensing when distributing binaries that include sqlite, no?
will this imply that I need to have an internet connection to make/install zope3 from checkouts? /dario -- -- ------------------------------------------------------------------- Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech. Lyrics applied to programming & application design: "emancipate yourself from mental slavery" - redemption song, b. marley
--On 22. Dezember 2005 12:44:23 -0330 Rocky Burt <rocky@serverzen.com> wrote:
Well, if we simply suck sqlite in as a build time requirement (during the 'make' process) do we care about importing non-ZPL code into svn.zope.org? We would only care about licensing when distributing binaries that include sqlite, no?
The sources must be part of the distribution so loading the package is not an option for me. But as Chris pointed out Sqlite is really free software. Since you volunteered (didn't you? :-) ) one should ask Jim about the license issue . Then the source should go at some location on svn.zope.org. The same applies to the SqliteDA (it's ZPL..maybe one should contact the author as well)....that's should not be too hard. So I am +0.75 to include Sqlite with Zope 2.10 (already deprecating Gadfly in 2.9 (I created already a copy of the ZGadyfly product on svn.zope.org). -aj
Rocky Burt schrieb:
Andreas Jung wrote:
--On 22. Dezember 2005 15:20:27 +0100 robert rottermann <robert@redcor.ch> wrote:
I perfectly agree with both of these arguments. However having a "dead easy to use" RDBMS tool is very convenient. Both for teaching and marketing purposes.
I agree (meanwhile) but we have to sort out the issues I mentioned already (license, integration with Z 3, who volunteers :-))
Hmm... I'm definitely willing to help out here. But one strike against me is my lack of zope3 development knowledge.
When you mentioned before about importing sqlite into svn.zope.org, you were talking about actually including a snapshot of sqlite inside zope source rather than making it a build time requirement?
I'd still rather not include depencies on other projects into the core. Even more if they are problematic license. And last not least - I'd not like zope bringing its own sqlite libs where I might have some in my python install already. I'm definitively -1 on including it in the core, no matter how usefull it migh appear. +1 in the list of suggested 3rd party products with "easy install"
Andreas Jung wrote:
Hi,
for next release we plan to replace several parts with the corresponding components from Zope 3 (e.g. ZPT´). Philipp is working on a proposal on that issue. In addition I would like to get rid of some old stuff that is no longer maintained and buggy:
- ZopeTutorial (could be ripped off without implications and made available for download on zope.org)
+1 Or write a new tutorial.
- HelpSys - from a programmers view pretty much useless and not very helpful. I consider to replace it with something more useful (not sure we can re-use apidoc from Zope 3 in some way, perhaps the inclusion of Dieter's Docfinder might be more useful for programmers)
+1 Never used it.
- Gadfly(DA) - do we really need this? We discussed this already. In my opinion the purpose of Gadfly is only educational but nothing that one really needs or uses for production. It could be removed and made available for download on zope.org.
-1 Gadfly is nice to experiment with SQL programming, you can even run small SQL apps (guestbook, small forum, etc.) with it. And it's easy to replace is with a more serious replacement afterwards. I've used it whenever I needed SQL support in Zope, either in development mode or in "hack something quickly" mode.
And my favourite enemy in Zope: ZClasses :-) I would like to mark them _clearly_ as an obsolete feature (DeprecationWarning, Warnings in the ZMI and the Zope Book). I _don't_ propose to remove them at some point but ppl should be aware that they are using one of the most-scary components in Zope (please no further discussion about the pros and cons of ZClasses..this discussion took already place already a bunch of times on the list).
+1 S. -- Stéfane Fermigier, Tel: +33 (0)6 63 04 12 77 (mobile). Nuxeo Collaborative Portal Server: http://www.nuxeo.com/cps Gestion de contenu web / portail collaboratif / groupware / open source!
participants (19)
-
Andreas Jung -
Chris McDonough -
Chris Withers -
Dario Lopez-Kästen -
Dennis Allison -
Florent Guillaume -
J Cameron Cooper -
Jeff Kowalczyk -
Jens Vagelpohl -
Jürgen Herrmann -
Lennart Regebro -
Martijn Faassen -
Max M -
Paul Winkler -
robert rottermann -
Rocky Burt -
Sidnei da Silva -
Stefane Fermigier -
Tino Wildenhain