Hi Sean, Thank you for your answer. Indeed collective.inviting helped me to use collective.subscribe and make everything i needed on my usecase.
I'm amazed by the work you have done on collective.subscribe. This is very useful, elegant and powerful. I hope it will become a standard. (I think i will rewrite using this api some other stuff with similar cases, where our implementation suffers some limitation - collective.favorites and collective.local.addgroup for example) On Fri, Jul 13, 2012 at 12:06 AM, Sean Upton <[email protected]> wrote: > Hi Thomas, > > collective.subscribe is potentially useful in concert with > collective.inviting (even if you ignore the UI bits from > collective.inviting). A few caveats and issue to be aware of: > > 1. I implemented the storage for the subscription catalog (indexes per > named relation of principal<-->content -- as subsciber-signature-tuple > to UIDs) are stored in a local utility when used by > collective.inviting. I am not happy with the risks associated with > this, and may soon change this to use annotations on the portal to > store the BTrees and replace the local utility with either an adapter > of the portal object or as a global adapter that uses getSite() to get > a venue for storage. This has been the major blocker from me > releasing the uu.inviting package to PyPI (only on github at the > moment). collective.subscribe itself has no pre-disposition as how > the persistent components for indexes are registered, only that they > are persistent objects somewhere inside a ZODB database. I agree with you (using annotation on portal instead of local utility in collective.inviting). If you do that, please write an upgrade step to migrate values. By the way, i think that collective.subscribe is ready for a release now. > > 2. The "signature" tuple storage format in collective.subscribe is > flexible enough to support both site members and guest users -- > usually these are stored using a signature like ('email', > '[email protected]') versus ('member', 'myuserid'). > > 3. Right now, the subscription that is indexed always assumes there is > a content item (or a UID-addressed object of some sort) that a > subscriber is subscribed to. Other types of relationships really are > not supported (if you need something more flexible, maybe consider > zc.relation-based solution). I'm okay with that > > Sean > > On Thu, Jul 12, 2012 at 8:22 AM, thomas desvenain > <[email protected]> wrote: >> Hi, >> >> I plan to use collective.subscribe as a dependency of a module i'm >> writing about subscribing users to digest notifications. >> collective.subscribe looks very good and very useful, but i'd like to >> see another product that uses it. >> >> do you know online examples of module using collective.subscribe as a >> dependency ? >> >> Thanks, >> >> Thomas >> >> -- >> Thomas Desvenain >> >> Téléphone : 09 51 37 35 18 >> _______________________________________________ >> Product-Developers mailing list >> [email protected] >> https://lists.plone.org/mailman/listinfo/plone-product-developers -- Thomas Desvenain Téléphone : 09 51 37 35 18 _______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
