[Zope-CMF] IndexableObjectWrapper

[Martin Aspeli]

yuppie wrote:
> Hi!
> 
> 
> Wichert Akkerman wrote:
>> Previously Jens Vagelpohl wrote:
>>> That's not the issue I was trying to address. I was specifically  
>>> talking about putting functionality in the most appropriate part of  
>>> the stack, meaning moving it further towards the core. If there are  
>>> bits and pieces that make more sense in the CMF then saying "well,  
>>> just install our package" may satisfy users, but developers will  
>>> continue wasting time maintaining different implementations.
>> Why would there be multiple implementations if they can just use the
>> existing one? I do not see that.
> 
> For the CMF project it is essential to have full control over its own 
> layer of the stack and to participate in the development of the Zope 
> layer. Using packages from the Plone repository means either using them 
> as a black box or joining the Plone Foundation to participate in their 
> development. IMO both options are not acceptable.

You don't need to join the Plone Foundation to develop packages in 
svn.plone.org. You *do* need to sign a contributor agreement granting 
some IP rights over that code to the Plone Foundation, in return for a 
promise that it will always be available under an open source license. 
There are no limits on who can sign that agreement or for what purpose 
they choose to work with the code in that repository.

Of course, the same goes for svn.zope.org: you need to sign a document 
and grant certain rights over your work to the Zope Foundation.

If CMF really cannot use packages not in svn.zope.org, then that's a bit 
sad and will invariably lead to a lot of re-invention rather than 
re-use. I don't really understand why it is "essential" to have this 
level of control over every line of code you use. This is entirely a 
self-imposed restriction.

>> I do agree that work should be in in
>> CMF itself, and this particular instance of the indexable wrappers is an
>> excellent example of that. I hope that in the last few years we have
>> already demonstrated that we really do want to work closer with the
>> CMF and Zope communities. 
> 
> For technical reasons this collaboration is asymmetric. Plone is built 
> on top of Zope and CMF, not the other way round. If you want to work 
> really close with these communities, you have to be part of them and use
> their repository.

I wrote a package that, I hope, is useful. I am pretty sure it'll work 
with "plain CMF" and therefore with other consumers of the CMF, and if 
doesn't, I'd consider that a bug and fix it. I'm willing to work to make 
that package a part of the CMF platform, whether optional or fully 
integrated.

To a certain extent, it already is: someone suing the CMF can choose to 
use plone.indexer in their own project, though they'll need to install 
it themselves. I don't quite see how this is asymmetric. Rather, it is 
an outcome of the evolution of this particular package.

It's up to the CMF maintainers to decide whether it is desirable to 
actually adopt this package as part of a standard release.

It's not always going to be appropriate (or even if it is, it's not 
always going to be the case) for every new line of code that *could* be 
useful to all/most CMF consumers to be built as part of the CMF itself 
from the outset. If the CMF project has no model for incorporating code 
from outside its (rather small) community, then I think that is more to 
the detriment of CMF than to those who created those packages and chose 
to put the effort in to reduce their dependencies and make them more 
generally useful.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book