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.

I think we all agree on this. In retrospect, it would've been a better 
idea to push for plone.indexer to be a part of CMF. However, I 
implemented it driven by Plone's release cycle and feature proposal 
process, which is why it ended up as it did. *I* want this feature for 
Plone, but it'd be even better if others could benefit.

Of course, it's not too late for that. If the license issue can be 
overcome (and I'm pretty sure that it will by April/May), then CMF can 
depend on plone.indexer if it so wants, and I'm willing to help make 
that possible if it means changing plone.indexer or helping with the CMF 
level implementation.

In the future, it may be that we can meet in the middle on this. When 
the PLIP process kicks off, it'd be good if the CMF developers had a 
look in as well. We should probably be better at announcing the various 
deadlines and proposals on this list, but if you guys see something that 
you feel would be a good fit further down, it doesn't hurt to raise 
that, lest the developer hasn't thought about it.

Martin

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

_______________________________________________
Zope-CMF maillist  -  Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests

Reply via email to