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 L. Drake, Jr.    <fdrake at gmail.com>
Zope Corporation
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to