[Product-Developers] modules using collective.subscribe ?

[thomas desvenain]

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 <sdupton at gmail.com> 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',
> 'me at example.com') 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
> <thomas.desvenain at gmail.com> 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
>> Product-Developers at lists.plone.org
>> https://lists.plone.org/mailman/listinfo/plone-product-developers



-- 
Thomas Desvenain

Téléphone : 09 51 37 35 18