On 9/30/05, Gary Poster <[EMAIL PROTECTED]> wrote: > A generally accessible web page has some advantages--it is easy to > read, and usable even if you don't have the most recent version of > the software, for instance. It has some problems too.
The up-to-dateness of the registry is what I'm most concerned about. That's why I like the external (to the software) registry. I'd expect many features to be defined and provided by third-party packages, so it's likely to be updated without regard to the Zope release schedule. > The biggest problem is that the registry is not maintained or found > within the source code: you have to look elsewhere to get the current > state, even when you are working in the code, and you also have to go > someplace else to edit it. Another is that our web site is sadly not > in shape to be a good tool: using a wiki is always a bit annoying, > and especially so at zope.org these days. While there are clearly problems, I don't think our wiki is so broken that we can't use it for something with a moderately low change rate like this (yes, I'm being predictive). > I propose that we actually store the registry in the Zope code, > probably in the package that defines the 'condition' attribute. We > even get a bit of web presence, thanks to svn.zope.org, for free. That would place it in zope.configuration. All the conditions that are currently defined in the Zope tree, other than in tests for the zcml:condition construct itself, are defined somewhere in zope.app, which suggests that there's a concept of "application domain" that might be pertinent. zope.configuration does not assume or require zope.app, or even that it will be used only in Zope. It's likely that it *is* only used in Zope, however. So we can have a registry (say, features.txt) in the zope.configuration package, and applications that have no requirement to support overlap with Zope code can simply ignore it. > A point that lands in either camp, depending on your position, is > that the wiki only requires site membership to edit, while the > repository approach gates it to contributers. Yes. The concern about having a larger set of contributors for the page is mostly an issue because more people would have the opportunity to remove entries or cause their meanings to change. Since I've not noticed a significant problem with WikiVandalism on zope.org wikis, I'm actually not worried about this. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> Zope Corporation _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com