Separate occurrence objects for plone.app.event?

[Róman Joost]

Hi,

I've been mailing with Johannes Raggam back and forth regarding the
current plone.app.event implementation and how to model a use case like
this:

    John, a plone user, creates multiple events which recur every month
    for two years.  He subscribes himself to an RSS feed created by a
    topic. After 5 Months he can not distinguish the events anymore, as
    they all show the dates when the event was created, but not each
    recurrence start/end dates.

We think it's better to discuss this on the mailing list, rather in
private.

As it currently looks, the DateRecurringIndex index is already providing
a good search interface to search for recurring events. Perhaps a
solution to address the use case would be to create occurrences as
individual objects. My hope with that approach is to show occurrences in
event listings as well as a separate view for an occurrence on a
recurring event. Most of the search forms, result pages and topics
should be able to deal with this approach gracefully.

An occurrence object could/should look all the same as it's event, but
obviously shows different start/end dates.

One additional bonus perhaps is even, that individual changes can be
stored.

Questions from my side:

    * What would be the performance impact in comparison with the
      current implementation. I saw there seems to be a boundary for
      unlimited events. I also saw that Lennart tried to address this
      issue.

If the discussion leads us to use individual objects for occurrences,
I'm happy to create a first implementation on a branch.

Thanks a lot for the current implementation and for all the work which
went into it. Well done!

Cheers,
--
Róman Joost

Mooball IT = Internet

13 Rowland Street
Coorparoo, Brisbane QLD 4151

mob: [phone]
skype: mooballdotcom
Tel: [phone]
Fax: [phone]
http://www.mooball.com

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Lennart Regebro-2]

On Mon, Apr 16, 2012 at 02:04, Róman Joost <[hidden email]> wrote:
>    John, a plone user, creates multiple events which recur every month
>    for two years.  He subscribes himself to an RSS feed created by a
>    topic.

RSS is not designed to handle events. So the answer is "don't do that".
There would, once everything is implemented, be an RFC5545 (aka
iCalendar) feed you can subscribe to.

>    After 5 Months he can not distinguish the events anymore, as
>    they all show the dates when the event was created, but not each
>    recurrence start/end dates.

If they have the same title he wouldn't be able to distinguish from
them immediattely.

> a good search interface to search for recurring events. Perhaps a
> solution to address the use case would be to create occurrences as
> individual objects.

Create what, more specifically, and how?

Are you actually proposing create recurrence objects in the content
space? That will become an unmanageable mess immediately, clutter the
UI and slow everything down. Creating the events when you save the
objects will take a very long time, and then you have to somehow keep
the created events synchronized with what the recurrence rule is,
which would amount to deleting and recreating all of them. The end
result is that every time you modify a recurring event saving it would
take a long time, in some cases minutes.

And how would you deal with events with infinite recurrence?

This is simply not a good idea.

> Questions from my side:
>
>    * What would be the performance impact in comparison with the
>      current implementation.

A complete disaster.

>      I saw there seems to be a boundary for
>      unlimited events. I also saw that Lennart tried to address this
>      issue.

Yeah, when I get time I'm replacing DateRecurringIndex with
plone.app.eventindex in plone.app.event and friends, which doesn't
have this problem.

//Lennart

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Jens W. klein-2]

On 2012-04-16 02:04, Róman Joost wrote:

> Hi,
>
> I've been mailing with Johannes Raggam back and forth regarding the
> current plone.app.event implementation and how to model a use case like
> this:
>
>      John, a plone user, creates multiple events which recur every month
>      for two years.  He subscribes himself to an RSS feed created by a
>      topic. After 5 Months he can not distinguish the events anymore, as
>      they all show the dates when the event was created, but not each
>      recurrence start/end dates.

So we need primary the information which distinct recurrence was
adressed somewhere.

> We think it's better to discuss this on the mailing list, rather in
> private.

+1 :)

> As it currently looks, the DateRecurringIndex index is already providing
> a good search interface to search for recurring events. Perhaps a
> solution to address the use case would be to create occurrences as
> individual objects. My hope with that approach is to show occurrences in
> event listings as well as a separate view for an occurrence on a
> recurring event. Most of the search forms, result pages and topics
> should be able to deal with this approach gracefully.
 >
> An occurrence object could/should look all the same as it's event, but
> obviously shows different start/end dates.

-1 We dont need real objects in ZODB.

We do only need the information which occurrence was adressed, i.e. as
an integer index. And with this information the addressed occurence can
be calculated.

> One additional bonus perhaps is even, that individual changes can be
> stored.

I think with the icalendar format this is already possible? CMIIW.

> Questions from my side:
>
>      * What would be the performance impact in comparison with the
>        current implementation. I saw there seems to be a boundary for
>        unlimited events. I also saw that Lennart tried to address this
>        issue.

As said I dont think this is a good idea, performance will be bad too.
Lennart proposes even to not create objects on catalog level but
calculate them on the fly therefore.

> If the discussion leads us to use individual objects for occurrences,
> I'm happy to create a first implementation on a branch.
>
> Thanks a lot for the current implementation and for all the work which
> went into it. Well done!

If an event recurring daily 3 times gets a new method "ocurrence"
returning a datetime by index::

     >>> event.ocurrence(self, 0)
     datetime.datetime(2012, 4, 16, 10, 21, 34, 444035)

     >>> event.ocurrence(self, 1)
     datetime.datetime(2012, 4, 17, 10, 21, 34, 444035)

     >>> event.ocurrence(self, 2)
     datetime.datetime(2012, 4, 18, 10, 21, 34, 444035)

     >>> event.ocurrence(self, 3)
     IndexError: list index out of range

This could be implemented by doing::

     >>> def ocurrence(self, idx):
     ...     return IRecurrence(obj).occurrences(range_start,
     ...                                         range_end)[idx]


The we could add a subpath or traverser to create IEvent implementing
non persistent objects on-the-fly using the index, i.e.::

     http://localhost:9090/Plone/myevent/++ocurrence++2

or::

     http://localhost:9090/Plone/myevent/ocurrenceview/2

An now we can use this url inside the feed or at other places where we
need some URL pointing to a distinct event.

Anyway, thats the easy part.

So we need this information at the catalog level too. Here it gets
difficult, because we have only one metadata object for one event in the
catalog - and it is very ok that way. But the way to just add the index
to the metadata (which would be the most natural way and what people
would expect) does not work therefore. Bad enough.

But we may use the current API to get the index of a brain and create a
utility function for this::

     >>> from plone.app.event import base
     >>> base.get_ocurrence_index(brain)
     2

This feels not that natural but would do it.

Just as an idea my 0.02€

Jens
--
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[johannes raggam]

hi all,

On Mon, 2012-04-16 at 10:04 +1000, Róman Joost wrote:

> Hi,
>
> I've been mailing with Johannes Raggam back and forth regarding the
> current plone.app.event implementation and how to model a use case like
> this:
>
>     John, a plone user, creates multiple events which recur every month
>     for two years.  He subscribes himself to an RSS feed created by a
>     topic. After 5 Months he can not distinguish the events anymore, as
>     they all show the dates when the event was created, but not each
>     recurrence start/end dates.

as lennart pointed out, i also do not think that storing each occurrence
as an individual object would be the way to go. actually i like the idea
of having a custom traverser to access each occurrence individually.

my answer to this issue in the discussion with róman was, that the
usecase can be solved from an UI viewpoint via different views:

the calendar portlet already displays each occurrence of a recurring
event separately under it's date (using base.get_events_by_date). but if
you access the event detail view, you just get a list of all occurrences
which makes it hard to find those of interest (especially if there are a
lot of occurrences which are batched over different pages). maybe we can
solve that like so:

  * passing a query parameter to the detail view or using a custom
    traverser with the occurrence id (as jens proposed). then this date
    is shown most prominent.

  * if no query parameter/custom traverser is used, show the most recent
    date most prominent.

the same applies for other event views, e.g. in folder listings or the
like.

> One additional bonus perhaps is even, that individual changes can be
> stored.

having different contents for each occurrence is a common usecase. e.g.
recurring theater plays in my hometown often have different start/end
times. maybe even different locations. exhibitions often have special
openings and closings.

this is supported by RFC5545/icalendar standard - but not by
plone.app.event at the moment.

i think we could annotate individual recurrence information (custom
text, different start/end times) on the event object with the recurrence
id (a property, which is defined by the RFC5545) as key.

but implementing this is out of scope for me at the moment. i'm happy
about any contributions!

cheers, hannes


--
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: [hidden email]
web:  http://programmatic.pro
      http://bluedynamics.com

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2

_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Róman Joost]

Hi Lennart,

On Mon, Apr 16, 2012 at 10:20:42AM +0200, Lennart Regebro wrote:
> On Mon, Apr 16, 2012 at 02:04, Róman Joost <[hidden email]> wrote:
> >    John, a plone user, creates multiple events which recur every month
> >    for two years.  He subscribes himself to an RSS feed created by a
> >    topic.
>
> RSS is not designed to handle events. So the answer is "don't do that".
> There would, once everything is implemented, be an RFC5545 (aka
> iCalendar) feed you can subscribe to.
>
Yes - already figured this one out. But you know users and their
expectations ...

> >    After 5 Months he can not distinguish the events anymore, as
> >    they all show the dates when the event was created, but not each
> >    recurrence start/end dates.
>
> If they have the same title he wouldn't be able to distinguish from
> them immediattely.
>
Good point.

> > a good search interface to search for recurring events. Perhaps a
> > solution to address the use case would be to create occurrences as
> > individual objects.
>
> Create what, more specifically, and how?
>
> Are you actually proposing create recurrence objects in the content
> space?
> [...]
>
> And how would you deal with events with infinite recurrence?
>
> This is simply not a good idea.

I was worried that will happen. Ok, forget the idea.

> Yeah, when I get time I'm replacing DateRecurringIndex with
> plone.app.eventindex in plone.app.event and friends, which doesn't
> have this problem.
Perhaps I could help with this too, if it's just replacing the start/end
indexes?

Cheers,
--
Róman Joost

*RECENT PROJECTS*
www.bullsmasters.com.au
www.pancreaticcancer.net.au
www.allanlanger.com.au
www.uonservices.org.au
www.asiapacificforum.net

Mooball IT = Internet

13 Rowland Street
Coorparoo, Brisbane QLD 4151

mob: [phone]
skype: mooballdotcom
Tel: [phone]
Fax: [phone]
http://www.mooball.com

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Róman Joost]

Hi Jens,

On Mon, Apr 16, 2012 at 11:00:21AM +0200, Jens W. Klein wrote:

> On 2012-04-16 02:04, Róman Joost wrote:
> > [...]
> > An occurrence object could/should look all the same as it's event, but
> > obviously shows different start/end dates.
>
> -1 We dont need real objects in ZODB.
>
> We do only need the information which occurrence was adressed, i.e. as
> an integer index. And with this information the addressed occurence can
> be calculated.

Point taken. Initially I had similar thoughts, but saw that this might
need changes of several views in Plone and it's content types.

> If an event recurring daily 3 times gets a new method "ocurrence"
> returning a datetime by index::
> [...]
>
> The we could add a subpath or traverser to create IEvent implementing
> non persistent objects on-the-fly using the index, i.e.::
> [...]
>
> Anyway, thats the easy part.
>
> So we need this information at the catalog level too.
> [...] does not work therefore. Bad enough.
>

I think either way would work: an index or a (start-) date of the
occurence.

Cheers,
--
Róman Joost

*RECENT PROJECTS*
www.bullsmasters.com.au
www.pancreaticcancer.net.au
www.allanlanger.com.au
www.uonservices.org.au
www.asiapacificforum.net

Mooball IT = Internet

13 Rowland Street
Coorparoo, Brisbane QLD 4151

mob: [phone]
skype: mooballdotcom
Tel: [phone]
Fax: [phone]
http://www.mooball.com

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Róman Joost]

Hi Johannes,

On Mon, Apr 16, 2012 at 11:46:13AM +0200, Johannes Raggam wrote:

> [...]
> the calendar portlet already displays each occurrence of a recurring
> event separately under it's date (using base.get_events_by_date). but if
> you access the event detail view, you just get a list of all occurrences
> which makes it hard to find those of interest (especially if there are a
> lot of occurrences which are batched over different pages). maybe we can
> solve that like so:
>
>   * passing a query parameter to the detail view or using a custom
>     traverser with the occurrence id (as jens proposed). then this date
>     is shown most prominent.
>
>   * if no query parameter/custom traverser is used, show the most recent
>     date most prominent.
>
> the same applies for other event views, e.g. in folder listings or the
> like.

Happy with that. Cheers!

> > One additional bonus perhaps is even, that individual changes can be
> > stored.
>
> having different contents for each occurrence is a common usecase. e.g.
> recurring theater plays in my hometown often have different start/end
> times. maybe even different locations. exhibitions often have special
> openings and closings.
>
> this is supported by RFC5545/icalendar standard - but not by
> plone.app.event at the moment.
>
> i think we could annotate individual recurrence information (custom
> text, different start/end times) on the event object with the recurrence
> id (a property, which is defined by the RFC5545) as key.

AAaah... good idea!

Let me see what I can do. I'd be happy to focus on the traversing after
talking to my boss as he acquired the funding.

What would be the best way to share this code? I just continue on my
fork with the implementation and issue pull requests or is there
anything better?

Cheers,
--
Róman Joost

*RECENT PROJECTS*
www.bullsmasters.com.au
www.pancreaticcancer.net.au
www.allanlanger.com.au
www.uonservices.org.au
www.asiapacificforum.net

Mooball IT = Internet

13 Rowland Street
Coorparoo, Brisbane QLD 4151

mob: [phone]
skype: mooballdotcom
Tel: [phone]
Fax: [phone]
http://www.mooball.com

------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Lennart Regebro-2]

On Tue, Apr 17, 2012 at 00:07, Róman Joost <[hidden email]> wrote:

> Hi Lennart,
>
> On Mon, Apr 16, 2012 at 10:20:42AM +0200, Lennart Regebro wrote:
>> On Mon, Apr 16, 2012 at 02:04, Róman Joost <[hidden email]> wrote:
>> >    John, a plone user, creates multiple events which recur every month
>> >    for two years.  He subscribes himself to an RSS feed created by a
>> >    topic.
>>
>> RSS is not designed to handle events. So the answer is "don't do that".
>> There would, once everything is implemented, be an RFC5545 (aka
>> iCalendar) feed you can subscribe to.
>>
> Yes - already figured this one out. But you know users and their
> expectations ...

Yeah, they need to be educated sometimes. It's not easy.

> Perhaps I could help with this too, if it's just replacing the start/end
> indexes?

The replacing is easy. Making sure it still works afterwards may not
be. You are welcome to try.

//Lennart

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[beams]

Jens W. klein-2 wrote

...
This could be implemented by doing::

     >>> def ocurrence(self, idx):
     ...     return IRecurrence(obj).occurrences(range_start,
     ...                                         range_end)[idx]


The we could add a subpath or traverser to create IEvent implementing
non persistent objects on-the-fly using the index, i.e.::

     http://localhost:9090/Plone/myevent/++ocurrence++2

or::

     http://localhost:9090/Plone/myevent/ocurrenceview/2

An now we can use this url inside the feed or at other places where we
need some URL pointing to a distinct event.

If we decide that you will only ever recur on a daily basis then surely the occurrence could be represented in the URL as a date i.e.

http://localhost:9090/Plone/myevent/ocurrenceview/2008-04-18

That would be much nicer for viewers, easier to interpret and guess. Better still

http://localhost:9090/Plone/myevent/2008-04-18

Jens W. klein-2 wrote

Anyway, thats the easy part.

So we need this information at the catalog level too. Here it gets
difficult, because we have only one metadata object for one event in the
catalog - and it is very ok that way. But the way to just add the index
to the metadata (which would be the most natural way and what people
would expect) does not work therefore. Bad enough.

But we may use the current API to get the index of a brain and create a
utility function for this::

     >>> from plone.app.event import base
     >>> base.get_ocurrence_index(brain)
     2

This feels not that natural but would do it.

Just as an idea my 0.02€

Jens

OK provided we have a brain for each occurrence then I think this will work, but it seems to me that you then face the task of building this logic into event listings, collections, search results and any other query that returns events. Thats an unfortunate task.

I noticed posts about 2 other things that Id like to comment on.

One is unlimited occurrences. As a practical person I do question the value of worrying about this. Its lovely to achieve if possible but if it poses practical problems then it seems it could turn into a lot of effort for a very rare case. I cant even imagine a case where it would not be practical to put some kind of end limit on a recurring event.

The second is variations of an events start time/end time or other properties. Again, Id take the pragmatic argument that if these properties vary then its not a recurring event, its a series of different events. Certainly on Google Apps, if you change anything about an event then it breaks the series and I think that would be generally accepted.

[beams]

Jens W. klein-2 wrote

...
This could be implemented by doing::

     >>> def ocurrence(self, idx):
     ...     return IRecurrence(obj).occurrences(range_start,
     ...                                         range_end)[idx]


The we could add a subpath or traverser to create IEvent implementing
non persistent objects on-the-fly using the index, i.e.::

     http://localhost:9090/Plone/myevent/++ocurrence++2

or::

     http://localhost:9090/Plone/myevent/ocurrenceview/2

An now we can use this url inside the feed or at other places where we
need some URL pointing to a distinct event.

If we decide that you will only ever recur on a daily basis then surely the occurrence could be represented in the URL as a date i.e.

http://localhost:9090/Plone/myevent/ocurrenceview/2008-04-18

That would be much nicer for viewers, easier to interpret and guess. Better still

http://localhost:9090/Plone/myevent/2008-04-18

Jens W. klein-2 wrote

Anyway, thats the easy part.

So we need this information at the catalog level too. Here it gets
difficult, because we have only one metadata object for one event in the
catalog - and it is very ok that way. But the way to just add the index
to the metadata (which would be the most natural way and what people
would expect) does not work therefore. Bad enough.

But we may use the current API to get the index of a brain and create a
utility function for this::

     >>> from plone.app.event import base
     >>> base.get_ocurrence_index(brain)
     2

This feels not that natural but would do it.

Just as an idea my 0.02€

Jens

OK provided we have a brain for each occurrence then I think this will work, but it seems to me that you then face the task of building this logic into event listings, collections, search results and any other query that returns events. Thats an unfortunate task.

I noticed posts about 2 other things that Id like to comment on.

One is unlimited occurrences. As a practical person I do question the value of worrying about this. Its lovely to achieve if possible but if it poses practical problems then it seems it could turn into a lot of effort for a very rare case. I cant even imagine a case where it would not be practical to put some kind of end limit on a recurring event.

The second is variations of an events start time/end time or other properties. Again, Id take the pragmatic argument that if these properties vary then its not a recurring event, its a series of different events. Certainly on Google Apps, if you change anything about an event then it breaks the series and I think that would be generally accepted.

[Róman Joost]

Hi Jens,

On Mon, Apr 16, 2012 at 11:00:21AM +0200, Jens W. Klein wrote:

> [...]
> If an event recurring daily 3 times gets a new method "ocurrence"
> returning a datetime by index::
>
>      >>> event.ocurrence(self, 0)
>      datetime.datetime(2012, 4, 16, 10, 21, 34, 444035)
>
>      >>> event.ocurrence(self, 1)
>      datetime.datetime(2012, 4, 17, 10, 21, 34, 444035)
>
>      >>> event.ocurrence(self, 2)
>      datetime.datetime(2012, 4, 18, 10, 21, 34, 444035)
>
>      >>> event.ocurrence(self, 3)
>      IndexError: list index out of range
>
> This could be implemented by doing::
>
>      >>> def ocurrence(self, idx):
>      ...     return IRecurrence(obj).occurrences(range_start,
>      ...                                         range_end)[idx]
>
>
> The we could add a subpath or traverser to create IEvent implementing
> non persistent objects on-the-fly using the index, i.e.::
> [...]
>
> But we may use the current API to get the index of a brain and create a
> utility function for this::
>
>      >>> from plone.app.event import base
>      >>> base.get_ocurrence_index(brain)
>      2

A catalog query returns the brain for the event and not for each
occurrence. That's what makes calculating now each occurences on the fly
in a view a bit tricky, because you loose all benefits of the catalogs
sorting mechanism.

Although in a discussion with Tom, he pointed out an interesting point
we forget with this solution: sorting. Doing a search for recurring
events will return each event. Afterwards I'll have to
re-sort/re-compile the search result by iterating over each event to
assemble the occurences which should be visible in the search result as
well.

Even if I have the brain, I will need access to the object to perform
this task.

Where am I missing something? Perhaps the API already returns the
occurences correctly sorted ...

Cheers,
--
Róman Joost

*RECENT PROJECTS*
www.bullsmasters.com.au
www.pancreaticcancer.net.au
www.allanlanger.com.au
www.uonservices.org.au
www.asiapacificforum.net

Mooball IT = Internet

13 Rowland Street
Coorparoo, Brisbane QLD 4151

mob: [phone]
skype: mooballdotcom
Tel: [phone]
Fax: [phone]
http://www.mooball.com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Lennart Regebro-2]

On Wed, Apr 18, 2012 at 03:33, Róman Joost <[hidden email]> wrote:
> A catalog query returns the brain for the event and not for each
> occurrence.

Yup. The catalog is for searching for objects. Returning multiple
brains for the same object would in most cases be confusing. A typical
usecase is to search for all events during a time period. If a search
in a search form was to search for all events in March, and you get 31
copies of one event, that's probably not what you want. Also, since
it's the same object, you'll have the same start and end date on all
of the objects anyway, so it doesn't really help you.

You want a list of all occurrences during the time period, and that's
a different kind of search. It's necessary and highly useful, but I'm
not convinced it should be an integral part of the catalog.

//Lennart

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[beams]

Lennart

On Wed, Apr 18, 2012 at 15:33, Lennart Regebro <[hidden email]> wrote:

On Wed, Apr 18, 2012 at 03:33, Róman Joost <[hidden email]> wrote:
> A catalog query returns the brain for the event and not for each
> occurrence.

Yup. The catalog is for searching for objects. Returning multiple
brains for the same object would in most cases be confusing. A typical
usecase is to search for all events during a time period. If a search
in a search form was to search for all events in March, and you get 31
copies of one event, that's probably not what you want. Also, since
it's the same object, you'll have the same start and end date on all
of the objects anyway, so it doesn't really help you.

You want a list of all occurrences during the time period, and that's
a different kind of search. It's necessary and highly useful, but I'm
not convinced it should be an integral part of the catalog.

//Lennart

So this brings us around in circles. We need the separate occurrences. If we do a search for events in march and it returns back say 10 objects, of which 5 may be recurring events, we then need to interrogate each of these 5 events again to find their occurrences, then merge the list of occurrences of each of those events into one list - re-sort them and then we can display our results. This means multiple queries and sorting all at the view level which seems crazy to me.

All of this leads me to the conclusion that we DO need separate objects for each occurrence - this would solve all these issues and remove the need for crazy re-querying of the recurring event objects. I know that creating objects for the occurrences may cause some kind of performance hit when editing, but I really want to know is that actually worse that this situation we are heading towards at the moment?

Tom

 

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Lennart Regebro-2]

On Wed, Apr 18, 2012 at 07:49, Tom Cameron <[hidden email]> wrote:
> So this brings us around in circles.

Absolutely not.

> We need the separate occurrences. If we
> do a search for events in march and it returns back say 10 objects, of which
> 5 may be recurring events, we then need to interrogate each of these 5
> events again to find their occurrences, then merge the list of occurrences
> of each of those events into one list - re-sort them and then we can display
> our results. This means multiple queries and sorting all at the view level
> which seems crazy to me.

Telling us that the catalog is the wrong place to do that sort of
search. It's not designed to be a calendar. Maybe it can be designed
to be it, but I'm still not convinced the catalog is the right place.

> All of this leads me to the conclusion that we DO need separate objects for
> each occurrence

That just causes even more and worse problems. So it's the wrong conclusion.

> but I really want to know is that actually worse that this
> situation we are heading towards at the moment?

Yes. And we are not "heading" to that situation, it is how it always
have been. It will be more obvious when recurring events is a part of
the core, but the situation has always been there.

It is great that more people want to help to improve the calendaring
support in Plone, but separate objects for each occurrence is not an
improvement.

//Lennart

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[beams]

Lennart

On Wed, Apr 18, 2012 at 16:58, Lennart Regebro <[hidden email]> wrote:

On Wed, Apr 18, 2012 at 07:49, Tom Cameron <[hidden email]> wrote:
> So this brings us around in circles.

> We need the separate occurrences. If we
> do a search for events in march and it returns back say 10 objects, of which
> 5 may be recurring events, we then need to interrogate each of these 5
> events again to find their occurrences, then merge the list of occurrences
> of each of those events into one list - re-sort them and then we can display
> our results. This means multiple queries and sorting all at the view level
> which seems crazy to me.

Telling us that the catalog is the wrong place to do that sort of
search. It's not designed to be a calendar. Maybe it can be designed
to be it, but I'm still not convinced the catalog is the right place.

> All of this leads me to the conclusion that we DO need separate objects for
> each occurrence

Absolutely not.

That just causes even more and worse problems. So it's the wrong conclusion.

> but I really want to know is that actually worse that this
> situation we are heading towards at the moment?

Yes. And we are not "heading" to that situation, it is how it always
have been. It will be more obvious when recurring events is a part of
the core, but the situation has always been there.

It is great that more people want to help to improve the calendaring
support in Plone, but separate objects for each occurrence is not an
improvement.

//Lennart

I really value your input but Im not sure this is getting me anywhere. 

My situation is that I have a client that needs recurring events happening and working in the next 2-3 weeks. Regardless of what you are doing we will be building a solution for them in that time. Ive really been hoping to collaborate with the community and contribute our efforts back, but to do that I need to understand exactly how you propose to solve these occurrence issues and then we can make sure that our efforts are in the same direction as yours and that our work is useful to the community.

You state "It will be more obvious when recurring events is a part of the core," but I need that to be obvious to me now, we cant wait any longer. So what Im asking is "how do you propose to handle the display of each occurrence? How do we find them? and sort them? Can you give us any direction at all that would allow us to build this now or are we just going to have to go it alone and build our own custom solution (which I would really hate to do but commercially I may be forced to do)?

Tom

--
Tom Cameron
Technical Director

Mooball IT

13 Rowland Street
Coorparoo, Brisbane QLD 4151

mob: [phone]
skype: mooballdotcom
Tel: [phone]
Fax: [phone]
http://www.mooball.com

RECENT PROJECTS

www.bullsmasters.com.au

www.pancreaticcancer.net.au

www.allanlanger.com.au

www.uonservices.org.au

www.asiapacificforum.net

WHAT'S NEW

- Mooball IT is now an authorised Google Apps Reseller - watch the video

- Google Apps now has rich text email signatures with images

- Plone 4 is now here upgrade to get new features and faster page loads.

- Register and renew your domain at Mooball Domains 

WEB AGENCY SPECIALISING IN PLONE DEVELOPMENT AND HOSTING
Plone CMS | Web Apps | Discount Domains | Web Hosting | Google Apps

Email disclaimer

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Jens W. klein-2]

On 2012-04-18 07:49, Tom Cameron wrote:

> Lennart
>
> On Wed, Apr 18, 2012 at 15:33, Lennart Regebro
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Wed, Apr 18, 2012 at 03:33, Róman Joost
>     <[hidden email]
>     <mailto:[hidden email]>> wrote:
>      > A catalog query returns the brain for the event and not for each
>      > occurrence.
>
>     Yup. The catalog is for searching for objects. Returning multiple
>     brains for the same object would in most cases be confusing. A typical
>     usecase is to search for all events during a time period. If a search
>     in a search form was to search for all events in March, and you get 31
>     copies of one event, that's probably not what you want. Also, since
>     it's the same object, you'll have the same start and end date on all
>     of the objects anyway, so it doesn't really help you.
>
>     You want a list of all occurrences during the time period, and that's
>     a different kind of search. It's necessary and highly useful, but I'm
>     not convinced it should be an integral part of the catalog.
>
>     //Lennart
>
>
> So this brings us around in circles. We need the separate occurrences.

As said, we have them already on the logical level. We just need a way
to adress them.

> If we do a search for events in march and it returns back say 10
> objects, of which 5 may be recurring events, we then need to interrogate
> each of these 5 events again to find their occurrences, then merge the
> list of occurrences of each of those events into one list - re-sort them
> and then we can display our results. This means multiple queries and
> sorting all at the view level which seems crazy to me.

We may improve the way we do this and add tools to libs such as
plone.app.event (or plone.event) to get the work off the programmer.

> All of this leads me to the conclusion that we DO need separate objects
> for each occurrence - this would solve all these issues and remove the
> need for crazy re-querying of the recurring event objects. I know that

And I believe this is wrong and must result in very bad performance.

> creating objects for the occurrences may cause some kind of performance
> hit when editing, but I really want to know is that actually worse that
> this situation we are heading towards at the moment?

Well, its the simplest solution to just replicate objects, but its not
an enterprise solution and will result in problems at some point..

Jens
--
Klein & Partner KG, member of BlueDynamics Alliance


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Lennart Regebro-2]

On Wed, Apr 18, 2012 at 09:09, Tom Cameron <[hidden email]> wrote:

My situation is that I have a client that needs recurring events happening and working in the next 2-3 weeks.

Well, define "working". :-)

I've been working on improving the state of calendaring for Plone since 2007. The only one that has been willing to invest money in that during this time is Nate Aune. From that situation, expecting that it now suddenly will be finished in 2-3 weeks is unrealistic. Calendaring is not an easy problem, it is a very large set of difficult ones.

As such, I hope that your definition of "working" is only a subset of what is needed for a complete solution.

That said, a complete solution isn't *that* far away, we are still hoping (possibly overoptimistically) that it will be done for Plone 4.3, which I think means at the end of the year or so. If you want anything of this faster, you'll have to put in significant manpower, or monetary resources.

Most if it is done and working as of today. But not everything.

Regardless of what you are doing we will be building a solution for them in that time. Ive really been hoping to collaborate with the community and contribute our efforts back, but to do that I need to understand exactly how you propose to solve these occurrence issues

What issues? The only actual issue mentioned here so far is that RSS doesn't work for recurring events. It's correct, it does not work, and will never work. RSS is not made for events and calendaring. What you need is iCalendar. I don't think there is an iCalendar solution for recurring events yet either, but that you could build in 2-3 weeks realistically, no problemo.

and then we can make sure that our efforts are in the same direction as yours and that our work is useful to the community.

The you need to join in the plone.app.event effort, managed by Johannes Raggam is leading, and see what you can do there to help finish it.

 

You state "It will be more obvious when recurring events is a part of the core," but I need that to be obvious to me now, we cant wait any longer.

If you and your customer have waited for a long time, I think it would have been good if you had made the community aware of this, and maybe see if the customer was willing to actually fund the development of this functionality, instead of just expecting it to be done by magic.

 

So what Im asking is "how do you propose to handle the display of each occurrence? How do we find them? and sort them?

All of these are open-ended questions where it is not obvious what your requirements are, or why you feel the current situation is problematic. As such it is impossible to answer in a useful manner.

Can you give us any direction at all that would allow us to build this now or are we just going to have to go it alone and build our own custom solution (which I would really hate to do but commercially I may be forced to do)?

I can promise you that building your own solution will take much longer than finishing plone.app.event.

This discussion is not constructive. Roman and you came here with a solution for a problem that is not really a problem (that RSS can't handle recurring events). This solution will create more problems than it solves. A real usable solution (use iCalendar) was proposed. Now you seem angry that we don't want to adopt your non-solution to your non-problem. I really don't see why this is so.

Have you taken a look at plone.app.event in it's current state? Do you have any concrete issues with it that you need solved before the 2-3 week deadline? Which are those? How do you propose to solve them?

//Lennart

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[beams]

Lennart,

First of all, Im so sorry if any previous messages sound rude. Im just struggling to get our questions across.

On Wed, Apr 18, 2012 at 22:09, Lennart Regebro <[hidden email]> wrote:

On Wed, Apr 18, 2012 at 09:09, Tom Cameron <[hidden email]> wrote:

My situation is that I have a client that needs recurring events happening and working in the next 2-3 weeks.

Well, define "working". :-)

I've been working on improving the state of calendaring for Plone since 2007. The only one that has been willing to invest money in that during this time is Nate Aune. From that situation, expecting that it now suddenly will be finished in 2-3 weeks is unrealistic. Calendaring is not an easy problem, it is a very large set of difficult ones.

As such, I hope that your definition of "working" is only a subset of what is needed for a complete solution.

That said, a complete solution isn't *that* far away, we are still hoping (possibly overoptimistically) that it will be done for Plone 4.3, which I think means at the end of the year or so. If you want anything of this faster, you'll have to put in significant manpower, or monetary resources.

Most if it is done and working as of today. But not everything.

Regardless of what you are doing we will be building a solution for them in that time. Ive really been hoping to collaborate with the community and contribute our efforts back, but to do that I need to understand exactly how you propose to solve these occurrence issues

What issues? The only actual issue mentioned here so far is that RSS doesn't work for recurring events. It's correct, it does not work, and will never work. RSS is not made for events and calendaring. What you need is iCalendar. I don't think there is an iCalendar solution for recurring events yet either, but that you could build in 2-3 weeks realistically, no problemo.

Ill define working and answer this in one go. Basically we need two things that the current product does not offer:

1. We need to be able to view each individual occurrence on its own. This is not terribly difficult, as everyone has suggested this could be achieved via some kind of URL query string or path.

2. We need any search to return each individual occurrence as a separate result. e.g. If I search for all events in May and there is a weekly recurring meeting I need to get 4 separate results each of which links to its own occurrence view. If I search Plone for all objects tagged 'blah' then I want to find all objects that match that keyword including all occurrences of any event that matches. This needs to work for general site searches and for collections, portlets, basically any place that you would naturally expect a search for events to work. Our highest priority would be collections because they are used to show things like 'upcoming events', but the main site search is also very important. You and I know that a recurring event is only one object in the database, but any site visitor would naturally expect each occurrence to behave as separate 'objects' anywhere you find events. Currently the only place this works is the calendar, except that it does not link to the occurrences.

In addition Ill state what we don't need:

1. We don't need infinite occurrences

2. We don't need occurrences to vary in any way other than the date, any variation in other properties such as description or time can be simply considered as a single event not part of the series

3. We actually don't need the ability to add or remove occurrences that are not part of the regular series. Though I see you have this feature already so that is handy.

 

and then we can make sure that our efforts are in the same direction as yours and that our work is useful to the community.

The you need to join in the plone.app.event effort, managed by Johannes Raggam is leading, and see what you can do there to help finish it.

 

You state "It will be more obvious when recurring events is a part of the core," but I need that to be obvious to me now, we cant wait any longer.

If you and your customer have waited for a long time, I think it would have been good if you had made the community aware of this, and maybe see if the customer was willing to actually fund the development of this functionality, instead of just expecting it to be done by magic.

The client only made us aware of their requirement about 4 weeks ago. And we only stumbled across this project about 2 weeks ago, so we had no way of informing anyone earlier. We are quite prepared to develop a solution for the client independently and its only once we found this project that we have started to investigate it and find out how it works and what its limitations it has (in relation to our client's requirements).

 

So what Im asking is "how do you propose to handle the display of each occurrence? How do we find them? and sort them?

All of these are open-ended questions where it is not obvious what your requirements are, or why you feel the current situation is problematic. As such it is impossible to answer in a useful manner. 

Can you give us any direction at all that would allow us to build this now or are we just going to have to go it alone and build our own custom solution (which I would really hate to do but commercially I may be forced to do)?

I can promise you that building your own solution will take much longer than finishing plone.app.event.

This discussion is not constructive. Roman and you came here with a solution for a problem that is not really a problem (that RSS can't handle recurring events). This solution will create more problems than it solves. A real usable solution (use iCalendar) was proposed. Now you seem angry that we don't want to adopt your non-solution to your non-problem. I really don't see why this is so.

Im sorry if it sounds that way, Im really just trying to be constructive. Im not sure why Roman mentioned RSS at all, that is not what we are looking for, I mentioned it as an example of a generic query that you would naturally expect to return each occurrence, it is not a specific requirement. My 2 points above more clearly indicate what we need for the client.

 

Have you taken a look at plone.app.event in it's current state?

Yes, we have been looking very closely at the code over the past 2 weeks and believe we understand how it works clearly. We are just not clear about the roadmap and how you plan to deal with searching for and displaying occurrences.

 

Do you have any concrete issues with it that you need solved before the 2-3 week deadline? Which are those? How do you propose to solve them?

See the 2 items above. As to how we propose to solve them - quite honestly we initially proposed to solve them by creating unique objects for each occurrence. But we are here discussing this because we want to know how you propose to solve them. If you have a clear plan and roadmap for these features then we would like to contribute and help. We raised this topic quite specifically to find out IF anyone has considered these items, and if so, HOW they are proposed to be achieved. We are only trying to find out if our client's objectives are in line with the community objectives and if that can result in constructive collaboration.

Again, please don't think Im angry, I really do value any input we can get and hope we can give back.

Tom

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Lennart Regebro-2]

On Wed, Apr 18, 2012 at 15:19, Tom Cameron <[hidden email]> wrote:
> 1. We need to be able to view each individual occurrence on its own. This is
> not terribly difficult, as everyone has suggested this could be achieved via
> some kind of URL query string or path.

I assume that with "on it's own" you mean that it needs a unique URL,
and that instead of showing a list of occurrences, it should show only
that occurrence?
I agree that traversal is the neatest way for that, and it shouldn't
be awfully tricky.

> 2. We need any search to return each individual occurrence as a separate
> result.

Really *any* search? Usually when you search for events that is a
specific type of search, with a start date and end date and maybe
location. You only want events back, and you want them listed with
date and time.

When you do a normal search, you want all types (except otherwise
specified), and you don't give any start or end dates or locations.
For normal searches, returning every occurrence of an event separately
is going to result in the recurring events showing up loads of times
and "pushing" other results down. It's normally not what you want at
all, and will make the generic search much less useful.

I'd suggest that you keep the event search separate from the generic
search. They are really quite different.

> e.g. If I search for all events in May and there is a weekly
> recurring meeting I need to get 4 separate results each of which links to
> its own occurrence view. If I search Plone for all objects tagged 'blah'
> then I want to find all objects that match that keyword including all
> occurrences of any event that matches. This needs to work for general site
> searches and for collections, portlets, basically any place that you would
> naturally expect a search for events to work. Our highest priority would be
> collections because they are used to show things like 'upcoming events'

You need specific recurrence event-aware views for that. p4a.calendar
implements that (it needs some cleanup though).

> the main site search is also very important. You and I know that a recurring
> event is only one object in the database, but any site visitor would
> naturally expect each occurrence to behave as separate 'objects' anywhere
> you find events.

Maybe they would expect that if you ask them, but the user experience
would be worse. I also don't think it is at all confusing if they
don't. See for example how Google search will hide "similar results".
If you do a generic search, you'll get all events, both in the past
and in the future, that matches what you look for, as well as
non-events like documents and news releases. Once you click on the
event you'll get a list of when the event happens (if it's more than
once). I don't find that one bit confusing, and I don't think other
people will either.

In fact, let's ask my wife, a good example of a "normal user".
...
Indeed, when asked, she said she would expect it to show up once for
each time the event happened (I used an opera played every day for
five weeks as example). When I then pointed out that this might mean
that the first one or two pages of the search result would be just one
thing repeated over and over but with different dates, her response
was "no, but that's horrible". Users might *expect* it. But it's not
what they *want*.

//Lennart

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[johannes raggam]

On Wed, 2012-04-18 at 23:19 +1000, Tom Cameron wrote:

> On Wed, Apr 18, 2012 at 22:09, Lennart Regebro <[hidden email]>
>        
>         Well, define "working". :-)

> Ill define working and answer this in one go. Basically we need two
> things that the current product does not offer:

> 1. We need to be able to view each individual occurrence on its own.
> This is not terribly difficult, as everyone has suggested this could
> be achieved via some kind of URL query string or path.
as discussed here, this would be more or less easily possible.

> 2. We need any search to return each individual occurrence as a
> separate result. e.g. If I search for all events in May and there is a
> weekly recurring meeting I need to get 4 separate results each of
> which links to its own occurrence view.
possible, if this search form uses get_events_by_date and a custom view,
together with a working implementation of your requirement 1), above.

>  If I search Plone for all objects tagged 'blah' then I want to find
> all objects that match that keyword including all occurrences of any
> event that matches. This needs to work for general site searches and
> for collections, portlets, basically any place that you would
> naturally expect a search for events to work.

for this requirement you have to store each occurrence as a seperate
object, since the SearchableText, Subject, etc. inidices do not consider
any recurrence rules.
but if you search for any portal type, does it make sense to mix
individual occurrences and other portal types in one view? sorting by
date makes not much sense here, if you mix events and non-events here.

how about that: the search returns just the one event object and
clicking on it doesn't get you to the event detail view but to a
calendar view where only filtered only by that one event. then the user
can select the date of interest, which brings him to a event-detail view
with information about that individual occurrence (via the
implementation of requirement 1), above).

of course, you have to create a couple of views for that. but this would
be easy.

> Our highest priority would be collections because they are used to
> show things like 'upcoming events', but the main site search is also
> very important. You and I know that a recurring event is only one
> object in the database, but any site visitor would naturally expect
> each occurrence to behave as separate 'objects' anywhere you find
> events. Currently the only place this works is the calendar, except
> that it does not link to the occurrences.

if you really need seperate objects, than you still can use
plone.app.event and override some functionality.

1) as index, use the normal DateIndex or configure DateRecurringIndex
without the recurdef attribute, so it defaults to None and only indexes
the start or end date.

2) extend the event object with an attribute (say,
occurrence_original_uid) which links all occurrences of an recurrence
sequence of an event together (e.g. via the UID) and create an index for
this attribute.

3) register an event subscriber for IObjectModifiedEvent and
IObjectCreatedEvent, which will create/delete the occurrence objects if
the recurrence rule changes.

4) override the IRecurrence adapter to use the occurrence_original_uid
index instead of plone.event.recurrence.recurrence_sequence_ical

that could work... without a guarantee ;)


or, create your own event implementation. maybe you'll still find some
tools from the plone.app.event stack useful.


side note: since the current DateRecurringIndex calculates every
occurrence at once (as opposed to the plone.app.eventindex, which might
get into plone.app.event when the time comes) and stores each occurrence
seperatly in the index, you can access those via some _underscore
methods. well, that's not supposed to be the API, but if you cannot rely
on calculating all occurrences of an event object (via
plone.event.recurrence.recurrence_sequence_ical) if you just want to
access one individual occurrence, this could be a way to go.
please note, the index stores datetimes converted to integer values in
UTC zone via plone.event.utils.dt2int. there is an reverse method:
plone.event.utils.int2dt.

e.g, for an ATEvent with some recurrence rule:

>>> from Products.CMFCore.utils import getToolByName
>>> cat = getToolByName(context, 'portal_catalog')
>>> cat_item = cat.searchResults(UID=context.UID())
>>> occurrences = cat.getIndexDataForRID(cat_item[0].getRID())['start']
>>> from plone.event.utils import int2dt
>>> [int2dt(item) for item in occurrences]


cheers,hannes


--
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: [hidden email]
web:  http://programmatic.pro
      http://bluedynamics.com

------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers