Hi Federico,
Thanks for the reply, plenty to go on here.
<snip>
> >
> > Also, I believe it leads to a number of problems :
> > - To ensure you have retrieved correctly over a range, you have
> > to initially retrieve _all_ components in the backend, expand
> > their recurrence rules in the client, and then check within
> > that given range.
>
> Ummm, not quite. Let me clarify.
>
<snip lots of good stuff from Federico>
OK. However, what I mean was that if you don't expand recurrence in your
storage, you have to have access to all the components to make sure that
they occur withing a range. Say I store an event that recurs every day, and
the first instance is on the 25th of June. The next day I start Evolution
and the query goes out for objects in the range 26th to 27th June. The
recurrence rules of the event stored on the 25th needs to expanded for an
instance of it to appear on the 26th/27th etc.
So I understand this as - all components with recurrence have their
recurrence expanded to satisfy "get_objects_inRange" type requests. I guess
I need to look at that code more closely.
> > - It makes it impossible to change recurring components in a
> > controlled way. Suppose I have an appointment that recurs every
> > week on Tuesday at 2pm. But this week I have to go someplace in
> > the afternoon and so I want to change this instance to occur at
> > 10am. If I update the component, all instances get changed,
> > which is not what I want at all.
>
> This is a canonical example from the IETF. You would add an exception
> date (EXDATE) to the component for this week's Tuesday and you would
> add an explicit recurrence date (RDATE) for 10am.
>
> Right now we do support editing EXDATEs but not RDATEs. (We do not
> support editing RDATEs or EXRULEs, but the actual recurrence engine
> should expand them correctly and they should actually occur at all the
> proper times for the views and alarms).
>
> RDATEs may be a bit of overkill within Evolution since in this context
> they are about the same as adding an EXDATE to the recurring component
> and then adding another component to the calendar at the time you
> want. You could even do this with cut&paste :)
If you take the approach of creating a new instance and adding an exdate, if
someone then goes and edits a _prior_ instance and wants their edit to apply
to all subsequent instances you start to have problems. It would be better
to have rdates. I'd like to see if I can get some time to look at this.
Maybe RELATED-TO could be used in this case, to maintain a link between the
components. I dunno, whenever I get into a conversation about recurrence it
just becomes an endless sequence of "yeah but if you do that..." statements
:-)
<snip again>
> Feel free to work on a patch to implement the API above; I don't know
> how much work would be required in the calendar views to use the
> Wombat in this way.
>
Again, yeah, I'd like to see if I can get time to work on this. In the
meantime, we hope to send some preliminary patches in the next couple of
days relating to iPlanet Calendar Server stuff.
Thanks,
Mike
--
Mike Hayes <[EMAIL PROTECTED]>
Sun Microsystems Ireland
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/evolution-hackers
