Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 03:33 , Martin Aspeli wrote: There are some discussions about licensing going on with the Plone Foundation, but chances are good that it can be licensed in such a way that CMF could adopt it you want. IMHO the licensing issue is of general interest beyond this one software bit. If there are any changes to Plone licensing I'm sure people on this list would be happy if you or someone else could provide some summary, if and when something is being changed :-) jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2GO0ACgkQRAx5nvEhZLJs9gCgo69+c0mzg4rIjDSO+h2DEUM1 H90AoIEzoTI2kkYlTq/dX483KZFsFBnc =8P7y -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Jens Vagelpohl wrote: Hi Jens, IMHO the licensing issue is of general interest beyond this one software bit. If there are any changes to Plone licensing I'm sure people on this list would be happy if you or someone else could provide some summary, if and when something is being changed :-) Some people including Wichert and Martin are pushing the Plone foundation to allow for an alternative license for Plone packages that are more of a underlying framework/library nature on request. As I see it, chances are good that we'll see this changing within the next few month even. At the moment, the discussion is about whether we (the Plone foundation) should generally allow one or several alternative licenses (- one seems to be the current favorite) and whether this one (if so decided) should be LGPL or BSD(-like). If there would be a strong preference from the CMF community here I'm sure this would be honored in our discussion. Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) Raphael jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2GO0ACgkQRAx5nvEhZLJs9gCgo69+c0mzg4rIjDSO+h2DEUM1 H90AoIEzoTI2kkYlTq/dX483KZFsFBnc =8P7y -END PGP SIGNATURE- ___ 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 ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Am 10.03.2009 um 09:14 schrieb Raphael Ritz: If there would be a strong preference from the CMF community here I'm sure this would be honored in our discussion. Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) Actually that is itself a very valid opinion - any company that is interested in software licences prefers as few of them as possible. My preference is always for a no-strings attached licence (ZPL, modifieid BSD, Apache). It's nice to hear that there is some discussion within Plone about licensing. If there is framework code in Plone that might be better placed lower down the stack in CMF then the sooner the better. There is a heap of stuff that could do with refactoring and reengineering along component architecture principles. It is not a little ironic in an open source context that the next release of Plone requires a new release of CMF to which it itself has (hardly?) contributed. This may often be unintentional as Plone developers write libraries for Plone unaware of the problem of backwards licence incompatability - the wrapper for z3c.forms springs to mind - but it is a problem just the same. Concentrating on a content management framework for Zope as the basis for Plone and other approaches is a good thing IMHO. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 09:14 , Raphael Ritz wrote: Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). In the end I hope that whatever decision is being made does not serve to widen the distance between the Plone community and the rest of the Zope universe. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2JqkACgkQRAx5nvEhZLJNMACeJvlVOK8y1hxx5dkyP1pmwP/M fqAAoJXXclf5a7Gy0tDiAhH5db0oCJLU =mIFf -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Previously Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 09:14 , Raphael Ritz wrote: Opinions anyone? (ideally including a reasoning beyond I want ZPL because that's what Zope itself uses) ;-) In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. It is, which is why the ZPL has already been rejected as an option: it is pretty much equivalent to the BSD license, which is much more widely accepted. The ZPL is a Zope Foundation-only license, while one goal of this push in Plone is to encourage wider adoption of generic components, even outside of the Zope community where possible. The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). I do not think the Plone Foundation board is willing to consider donating some of its intellectual property to the Zope Foundation. I am already happy they are willing to consider selective relicensing. But that does not need to be a problem: reusable packages such as plone.indexer can be used by CMF even if they are not covered by the ZPL or managed in svn.zope.org, as long as there is the license is acceptable. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Am 10.03.2009 um 10:01 schrieb Wichert Akkerman: The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. Speaking as someone who hasn't written a whole lot of code: BSD. I have a real dislike of the GPL because I think it fails to emphasise the real benefits of open source and it is a real pain if you wish to integrate with other non-GPL stuff whether it's commercial or not. The same discussion came up for Trac a few years ago because of the desire for closer integration with subversion. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. It is, which is why the ZPL has already been rejected as an option: it is pretty much equivalent to the BSD license, which is much more widely accepted. If they are equivalent, why not dual-license? The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. The discussion has been rehashed in several places, but given a choice between pretty much anything and the GPL I'd vote -1 on the GPL. As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). I do not think the Plone Foundation board is willing to consider donating some of its intellectual property to the Zope Foundation. I am already happy they are willing to consider selective relicensing. To me this really sounds like the rift has widened, by a whole lot. It reads like we're happy to base our stuff on yours, but we really don't want to give back. I'm sure it's not meant that way, but it reads like that. But that does not need to be a problem: reusable packages such as plone.indexer can be used by CMF even if they are not covered by the ZPL or managed in svn.zope.org, as long as there is the license is acceptable. 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. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2NA8ACgkQRAx5nvEhZLLy0wCfehi6WBVBHEcwJZXORFpM2tx4 aD4Anip87gouzSsnK/o4jI57ibOjt3YS =dvw+ -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Previously Jens Vagelpohl wrote: On Mar 10, 2009, at 10:01 , Wichert Akkerman wrote: Previously Jens Vagelpohl wrote: In general, commercial adoption of a software stack is made easier if it is not accompanied by a whole soup of different licenses. The fewer licenses, the better. I'm sure that issue is on your radar already. It is, which is why the ZPL has already been rejected as an option: it is pretty much equivalent to the BSD license, which is much more widely accepted. If they are equivalent, why not dual-license? What would the advantage be? The ZPL is an exercise of license proliferation and as far as I can see gives no benefits over BSD. The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. The discussion has been rehashed in several places, but given a choice between pretty much anything and the GPL I'd vote -1 on the GPL. I made a typo there: the discussion is focusing on LGPL versus BSD. I suspect that will not change your vote though :) As you know, all code you'd like pushed down the stack into the CMF or Zope must be licensed under the ZPL. That's also a prerequisite for being stored in the Zope Foundation repositories (a.k.a. svn.zope.org). I do not think the Plone Foundation board is willing to consider donating some of its intellectual property to the Zope Foundation. I am already happy they are willing to consider selective relicensing. To me this really sounds like the rift has widened, by a whole lot. It reads like we're happy to base our stuff on yours, but we really don't want to give back. I'm sure it's not meant that way, but it reads like that. It is not that way at all. Plone does want to give back, and by relicensing components does exactly that. If the BSD is chosen you can do anything you want with that Plone code, except upload it to svn.zope.org since that implies transferring ownership, which is not allowed. This is no different than Zope policies: you can not copy code from svn.zope.org to the plone repository either. Or move code from Repoze to Zope, from Zope to FSF, etc. etc. The license is not the limiting factor there, but the surrounding policies are. But that does not need to be a problem: reusable packages such as plone.indexer can be used by CMF even if they are not covered by the ZPL or managed in svn.zope.org, as long as there is the license is acceptable. 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. 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. Perhaps in the future the Plone Foundation would be willing to donate code to the Zope Foundation. At this moment that is a bridge too far, and I fear that as soon as I suggest that at this point in time the entire relicensing movement will die in a never-ending debate. Lets save that one for a later day. Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
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
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 11:08 , Martin Aspeli wrote: 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. IMHO the release cycle argument doesn't wash. We've always had CMF releases in preparation for important Plone releases, and I'm happy to continue that. 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. Thanks, I appreciate that. Generally, I think now that the ZF has cleared up the remaining issues about code ownership etc. we finally have two entities, the ZF and the Plone Foundation, that are the perfect platform for official issues like code donations, or for coordinating other cooperation issues. I can't judge how the Plone Foundation acts within the Plone community, but as far as the Zope Foundation goes, Martijn has been doing a lot of work to make it more relevant and an important player in the actual software development process. 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. Is there any kind of low-traffic announcement list for things like PLIPs? I'm not subscribed to any Plone list because of (for me at least) signal to noise ratio fears. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2PwIACgkQRAx5nvEhZLJs8QCfYsGqkD63R9+isOhA0nXzeWy+ IgoAoJ8xfUzIMdGmlOSXUEreYgF7ErI+ =owJ7 -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
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. 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. Cheers, Yuppie ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Thanks! You already noticed that the wrapper is instantiated directly, so that's what's going on. No magic, no component architecture. Thanks for the clarification. The bits that confused me were: class IndexableObjectSpecification(ObjectSpecificationDescriptor) ... class IndexableObjectWrapper(object): implements(IIndexableObjectWrapper) __providedBy__ = IndexableObjectSpecification() What does this code actually achieve (I get the implements bit, obviously)?! Whether that is good or bad or should be changed is a different issue. I will write up a short proposal. Miles ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Thanks Can anyone tell me if it is possible to register an adapter to snip This should work with plain CMF and be simple to hook into the catalogue tool. (For me) this is the root of the problem - it can only be hooked into the catalog by subclassing at the moment, there is no other mechanism to use different implementations. If there was, then plone.indexer (or whatever) could be used directly. Therefore, can I make a proposal (which I am happy to carry out), as I think this is a desirable change? PROPOSAL: Use CA to look up the indexable object wrapper PROBLEM: It is not possible to provide alternative implementations of the IndexableObjectWrapper class at the moment - this prevents customising the indexing process. SOLUTION: Look up the IndexableObjectWrapper using the Component Architecture. The catalog tool will look up a named utility that creates a wrapped object suitable for indexing. The default implementation of the utility will return the object wrapped using the current IndexableObjectWrapper. If required, Local Site configuration can be used to provide different implementations as needed. BACKWARDS COMPATIBILITY: Any catalog implementation that used a different wrapper class would have to subclass the main catalog and override the relevant function, so will be unaffected by the change. Any thoughts? Miles ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
On 3/10/09 1:17 AM, Charlie Clark char...@begeistert.org wrote: Am 10.03.2009 um 10:01 schrieb Wichert Akkerman: The debate is currently focusing on GPL versus BSD license. Any opinions on a choice between those two would be very welcome. ...: BSD. +2 Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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 ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Hi! Miles wrote: Thanks for the clarification. The bits that confused me were: class IndexableObjectSpecification(ObjectSpecificationDescriptor) ... class IndexableObjectWrapper(object): implements(IIndexableObjectWrapper) __providedBy__ = IndexableObjectSpecification() What does this code actually achieve (I get the implements bit, obviously)?! This makes the wrapper transparent, allowing the index to look up adapters for the interfaces of the object. TextIndexNG3 works that way. Whether that is good or bad or should be changed is a different issue. I will write up a short proposal. AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Cheers, Yuppie ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Am 10.03.2009 um 10:49 schrieb Wichert Akkerman: Perhaps in the future the Plone Foundation would be willing to donate code to the Zope Foundation. At this moment that is a bridge too far, and I fear that as soon as I suggest that at this point in time the entire relicensing movement will die in a never-ending debate. Lets save that one for a later day. I suspect you're right on that and that we on this list can all say that, with hindsight, the licence debate should never have happened. Let's hope it can be resolved in the future. I hope this will become easier as development moves to a more library-based approach -- all hail TurPlango! What we cannot (dual-)license for the CMF but think we need for the CMF we will have to reimplement. I have to agree with Jens that saying something was added to Plone rather than the CMF because of the Plone release cycle is disingenuous. As long as I have been following the list the CMF releases have been timed for Plone. It would be good to see this change from now on as I suspect the number of core developers on both projects is limited and both projects would benefit from effectively pooled resources and clear ideas of what goes where. I also have to agree with Jens that the Plone mailing lists are way too noisy. Charlie -- Charlie Clark Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-938-5360 GSM: +49-178-782-6226 ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
class IndexableObjectWrapper(object): implements(IIndexableObjectWrapper) __providedBy__ = IndexableObjectSpecification() What does this code actually achieve (I get the implements bit, obviously)?! This makes the wrapper transparent, allowing the index to look up adapters for the interfaces of the object. TextIndexNG3 works that way. Brilliant! Now it all makes sense. Any objections to me adding some comments into IndexableObjectSpecification to this effect? Mile ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
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 ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Hi Miles, This should work with plain CMF and be simple to hook into the catalogue tool. (For me) this is the root of the problem - it can only be hooked into the catalog by subclassing at the moment, there is no other mechanism to use different implementations. If there was, then plone.indexer (or whatever) could be used directly. Therefore, can I make a proposal (which I am happy to carry out), as I think this is a desirable change? PROPOSAL: Use CA to look up the indexable object wrapper +1 - Plone already has this, and it's pretty easy to do. If CMF got this, then Plone could drop its own custom adapter and use the CMF one to hook in plone.indexer, as could anyone else wanting to use this package. PROBLEM: It is not possible to provide alternative implementations of the IndexableObjectWrapper class at the moment - this prevents customising the indexing process. SOLUTION: Look up the IndexableObjectWrapper using the Component Architecture. The catalog tool will look up a named utility that creates a wrapped object suitable for indexing. Actually, I'd suggest you look it up as an adapter on the object being indexed. Also, it probably shouldn't be named, as there's nothing to switch the name on. The default implementation of the utility will return the object wrapped using the current IndexableObjectWrapper. If required, Local Site configuration can be used to provide different implementations as needed. BACKWARDS COMPATIBILITY: Any catalog implementation that used a different wrapper class would have to subclass the main catalog and override the relevant function, so will be unaffected by the change. Any thoughts? +1 in general 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
Re: [Zope-CMF] IndexableObjectWrapper
Jens Vagelpohl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 11:08 , Martin Aspeli wrote: 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. IMHO the release cycle argument doesn't wash. We've always had CMF releases in preparation for important Plone releases, and I'm happy to continue that. I'm not arguing. I'm saying that it didn't really cross my mind, because I was improving something that was already Plone specific (the ExtensibleIndexableObjectWrapper) in response to a Plone demand and working towards a Plone deadline. Hindsight is a good thing, and maybe it would've been better to try to all of it down into the stack. In this case, I didn't. Except that I kind of did... I created a package with no other Plone dependencies, in the hope that it *could* be useful. I didn't take the time to discuss it on this list, which I should have. However, the desire for it to be re-usable by other CMF consumers is clearly in evidence. 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. Thanks, I appreciate that. Generally, I think now that the ZF has cleared up the remaining issues about code ownership etc. we finally have two entities, the ZF and the Plone Foundation, that are the perfect platform for official issues like code donations, or for coordinating other cooperation issues. I can't judge how the Plone Foundation acts within the Plone community, but as far as the Zope Foundation goes, Martijn has been doing a lot of work to make it more relevant and an important player in the actual software development process. Indeed! Bear in mind that the Plone Foundation has an explicit goal *not* to interfere with software development. However, it does deal with issues of IP and so I agree the two foundations are the right forum for this type of thing. 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. Is there any kind of low-traffic announcement list for things like PLIPs? I'm not subscribed to any Plone list because of (for me at least) signal to noise ratio fears. There's plone-announce, but I don't think this was announced there. I actually think the Plone release manager should cross-post a few important announcements to this list, though. The actual feature discussion happens on the medium-traffic framework-team list, which you can join. In fact, it'd be great if you did, as we'd appreciate your input, but I realise it may not be something you want to spend a lot of time on. 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
Re: [Zope-CMF] IndexableObjectWrapper
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mar 10, 2009, at 14:21 , Martin Aspeli wrote: The actual feature discussion happens on the medium-traffic framework-team list, which you can join. In fact, it'd be great if you did, as we'd appreciate your input, but I realise it may not be something you want to spend a lot of time on. I'll join, sure. Joining does not imply activity beyond reading ;-) If there was a narrow-scoped announce-type list that contains announcements like PLIPs or important development decisions that may be of interest to the CMF developers as well then it would be useful to pipe it into this list. That's one reason I asked. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkm2bQkACgkQRAx5nvEhZLKP4wCeK5mW5+r4Ie0s1sghrz20zqWG gDgAnjQelFAI2qdpRiZMCog+JpCIGW0s =JEV8 -END PGP SIGNATURE- ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Martin Aspeli wrote: Jens Vagelpohl wrote: Is there any kind of low-traffic announcement list for things like PLIPs? I'm not subscribed to any Plone list because of (for me at least) signal to noise ratio fears. There's plone-announce, but I don't think this was announced there. plone-announce is targeted at consumers of Plone, so has information like New Symposium coming up, Plone 3.2 released. I actually think the Plone release manager should cross-post a few important announcements to this list, though. We could probably do that. There is a lot of information which isn't relevant at all to the CMF level nor the Zope level in the same ways. The actual feature discussion happens on the medium-traffic framework-team list, which you can join. In fact, it'd be great if you did, as we'd appreciate your input, but I realise it may not be something you want to spend a lot of time on. One way to get quite a filtered list is to look at the PLIP's themselves from time to time. For Plone 3.3 this is: http://plone.org/products/plone/releases/3.3 We can make sure to post the important dates for our release process to this list and provide at least this kind of URL. For Plone 4.0 we haven't probably started the process yet (my fault) but have some things available in the listing at: http://dev.plone.org/plone/milestone/4.0 The items on the 4.0 list here are basically all of my personal pet peeves and there's a lot of more things we are going to do, like completely revamp the admin UI and probably use Dexterity for the default types, while retaining backwards compatible support with Archetypes. Hanno ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
yuppie wrote: AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Bear in mind that there is a difference between getting the wrapper itself, and getting the value to catalogue for a particular *attribute* of the wrapper (e.g. allowedRolesAndUsers). The CatalogTool subclass in Plone solves the former. plone.indexer uses the hook it puts in place to solve the latter. I think at a minimum, CMF should just make the whole wrapper swappable by looking it up as an adapter. Then people could choose to use plone.indexer if they so needed (we'd obviously need to change plone.indexer to provide an appropriate adapter based on a CMF interface rather than a Plone one, and then deprecate the Plone version). For smaller applications, it may just be unnecessary complexity. 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
Re: [Zope-CMF] IndexableObjectWrapper
Hi Martin! Martin Aspeli wrote: yuppie wrote: 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. Just to make it clear: I'm talking about the code in the CMF and the Zope layer. Not about lower level layers. I'm absolutely fine with having Python and some other libraries in different repositories. And I'm not talking about CMF users. I'm sure there are good reasons to use Plone libraries together with the CMF. I'm talking about closely related code. Maintaining it in different repositories with different code ownership, license and policies creates extra costs. Either everybody has to work in both repositories or you have to ask people to make changes are releases. Refactoring code across repository boundaries becomes almost impossible. 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. I don't think it's the role of the CMF project to integrate all the code that could be useful for people building applications. Others like Plone can do that much better. The CMF has to become simpler, not more complex. Third party products always add complexity. Incorporating new code means replacing old code in a backwards compatible way, not just adding another hook. Code evolution is useful, but it can't replace discussions and consolidation. Cheers, Yuppie ___ 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
Re: [Zope-CMF] IndexableObjectWrapper
Martin Aspeli wrote: yuppie wrote: AFAICS wrapping the object before looking up adapters is unnecessary. The catalog should do the lookup directly and the existing features provided by IndexableObjectWrapper should be reimplemented as adapters. Bear in mind that there is a difference between getting the wrapper itself, and getting the value to catalogue for a particular *attribute* of the wrapper (e.g. allowedRolesAndUsers). Why do we need the wrapper? Why can't we look up directly the adapter for the particular attribute? Cheers, Yuppie ___ 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
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py Clean out module-scope imports.
Tres Seaver wrote: Log message for revision 97800: Clean out module-scope imports. Changed: U Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py -=- Modified: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py === --- Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py 2009-03-10 12:59:04 UTC (rev 97799) +++ Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py 2009-03-10 13:20:03 UTC (rev 97800) @@ -16,17 +16,7 @@ import unittest -import Testing -from AccessControl.SecurityManagement import getSecurityManager -from AccessControl.SecurityManagement import newSecurityManager -from DateTime import DateTime -from zope.interface.verify import verifyClass - -from Products.CMFCore.tests.base.dummy import DummyContent -from Products.CMFCore.tests.base.dummy import DummySite -from Products.CMFCore.tests.base.security import OmnipotentUser -from Products.CMFCore.tests.base.security import UserWithRoles from Products.CMFCore.tests.base.testcase import SecurityTest What was wrong with these imports? Cheers, Yuppie ___ 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
Re: [Zope-CMF] SVN: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py Clean out module-scope imports.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yuppie wrote: Tres Seaver wrote: Log message for revision 97800: Clean out module-scope imports. Changed: U Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py -=- Modified: Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py === --- Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py 2009-03-10 12:59:04 UTC (rev 97799) +++ Products.CMFCore/trunk/Products/CMFCore/tests/test_CatalogTool.py 2009-03-10 13:20:03 UTC (rev 97800) @@ -16,17 +16,7 @@ import unittest -import Testing -from AccessControl.SecurityManagement import getSecurityManager -from AccessControl.SecurityManagement import newSecurityManager -from DateTime import DateTime -from zope.interface.verify import verifyClass - -from Products.CMFCore.tests.base.dummy import DummyContent -from Products.CMFCore.tests.base.dummy import DummySite -from Products.CMFCore.tests.base.security import OmnipotentUser -from Products.CMFCore.tests.base.security import UserWithRoles from Products.CMFCore.tests.base.testcase import SecurityTest What was wrong with these imports? I don't like module-scope imports in unit tests: I want tests to *fail*, not be skipped, when something is not importable. I put my rationale in this blog entry: http://palladion.com/home/tseaver/obzervationz/2008/unit_testing_notes-20080724 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJtrFn+gerLs4ltQ4RAhOAAKCS/QoCbex5FOE+CevM4oPS0bVU5wCgocg7 bPxq/nV3CaSX/0CFtPvsaOQ= =Wzi8 -END PGP SIGNATURE- ___ 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
