[GSoC 2013] Possible Architecture for Recurrence Events Implementation

[Dishara Wijewardana <dd...@gmail.com>]

Hi all,

I have updated the JIRA with a possible architecture diagram[1] for Open
Meetings Recurrence events implementation.

Here in the diagram, IcalHandler is the one which is already there in the
OpenMeetings core as org.apache.openmeetings.utils.mail.IcalHandler.
I thought of implementing the Recurrence Event Handler on top of this (by
expanding the Icalhandler class) where Recurrence Event Handler will keep
the state of the events and manage everything in related to recurrences and
provide an abstract interface which can be used  by any core module of the
OpenMeetings. In other words open meetings front end will not directly call
to the Recurrence Event Handler interface but to some adapter in the core
which will deal with the aforementioned handler.

This way I feel the separation of concerns will meet and we will not
tightly coupled with any iCalculator vendor (which is already happening now
through the IcalHandler).
 Appreciate your valuable feedback on this architecture.

[1] -
https://issues.apache.org/jira/secure/attachment/12575505/recurrence-event-arch.jpg

-- 
Thanks
/Dishara

Re: [GSoC 2013] Possible Architecture for Recurrence Events Implementation

[Dishara Wijewardana <dd...@gmail.com>]

On Tue, Mar 26, 2013 at 5:00 PM, Maxim Solodovnik <so...@gmail.com>wrote:

> I believe it is not the big deal how to set recurrences in *.ics files.
> import should support both, export can support any.
> The main problem is Database.
> It should be possible to get the list of instances of recurring
> event intersecting given period of time.
>

I infact assumed that OpenMeetings events directly deals with the ical4j
API and we persist the events through ical4j. As per your explanation, it
is not the case.
So we are persisting the events in our own persistent layer
while in-cooperate with the ical4j API.

In that case we need a Recurrence Event Manager who wraps the previously
mentioned Recurrence event handler (or IcalHandler) and at
#calculateRecurrences(Period) it will fetch the recurrence events from the
DB. And when creating a recurrence event #createRecurrenceEvent(HEvent)
will persist the HEvent meta data to the DB.

Please correct me if I am wrong/or am I missing any part ?


> For ex.:
> 1) you have create annual event in 2002.03.25 (My best friend's birthday)
> 2) you open calendar and select March 2013
> Event created in 2002 should be displayed.
>
> Additionally these events should be editable in "All", "This" and "This and
> later" modes
>
> IcalHandler is necessary for export/import only: 10 lines of code :)
>
>
>
> On Tue, Mar 26, 2013 at 6:19 PM, Dishara Wijewardana <
> ddwijewardana@gmail.com> wrote:
>
> > Hi all,
> >
> > I have updated the JIRA with a possible architecture diagram[1] for Open
> > Meetings Recurrence events implementation.
> >
> > Here in the diagram, IcalHandler is the one which is already there in the
> > OpenMeetings core as org.apache.openmeetings.utils.mail.IcalHandler.
> > I thought of implementing the Recurrence Event Handler on top of this (by
> > expanding the Icalhandler class) where Recurrence Event Handler will keep
> > the state of the events and manage everything in related to recurrences
> and
> > provide an abstract interface which can be used  by any core module of
> the
> > OpenMeetings. In other words open meetings front end will not directly
> call
> > to the Recurrence Event Handler interface but to some adapter in the core
> > which will deal with the aforementioned handler.
> >
> > This way I feel the separation of concerns will meet and we will not
> > tightly coupled with any iCalculator vendor (which is already happening
> now
> > through the IcalHandler).
> >  Appreciate your valuable feedback on this architecture.
> >
> > [1] -
> >
> >
> https://issues.apache.org/jira/secure/attachment/12575505/recurrence-event-arch.jpg
> >
> > --
> > Thanks
> > /Dishara
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>



-- 
Thanks
/Dishara

Re: [GSoC 2013] Possible Architecture for Recurrence Events Implementation

[Maxim Solodovnik <so...@gmail.com>]

I believe it is not the big deal how to set recurrences in *.ics files.
import should support both, export can support any.
The main problem is Database.
It should be possible to get the list of instances of recurring
event intersecting given period of time.

For ex.:
1) you have create annual event in 2002.03.25 (My best friend's birthday)
2) you open calendar and select March 2013
Event created in 2002 should be displayed.

Additionally these events should be editable in "All", "This" and "This and
later" modes

IcalHandler is necessary for export/import only: 10 lines of code :)



On Tue, Mar 26, 2013 at 6:19 PM, Dishara Wijewardana <
ddwijewardana@gmail.com> wrote:

> Hi all,
>
> I have updated the JIRA with a possible architecture diagram[1] for Open
> Meetings Recurrence events implementation.
>
> Here in the diagram, IcalHandler is the one which is already there in the
> OpenMeetings core as org.apache.openmeetings.utils.mail.IcalHandler.
> I thought of implementing the Recurrence Event Handler on top of this (by
> expanding the Icalhandler class) where Recurrence Event Handler will keep
> the state of the events and manage everything in related to recurrences and
> provide an abstract interface which can be used  by any core module of the
> OpenMeetings. In other words open meetings front end will not directly call
> to the Recurrence Event Handler interface but to some adapter in the core
> which will deal with the aforementioned handler.
>
> This way I feel the separation of concerns will meet and we will not
> tightly coupled with any iCalculator vendor (which is already happening now
> through the IcalHandler).
>  Appreciate your valuable feedback on this architecture.
>
> [1] -
>
> https://issues.apache.org/jira/secure/attachment/12575505/recurrence-event-arch.jpg
>
> --
> Thanks
> /Dishara
>



-- 
WBR
Maxim aka solomax