[Kde-pim] Kcal and RecurrenceID

[Allen Winter]

Hi Álvaro!


On Tuesday 04 August 2009 4:06:53 am Álvaro Manera wrote:
> Hi again,
> 
> I continue with this topic to see if I get ideas from somebody. I tried 
> yesterday again in IRC, so maybe here there is a wider audience.
> 
Yes, I saw your ideas the IRC yesterday.  Sorry I wasn't around at the time.

> To implement the RecurrenceID inside Kcal I have a couple of ideas on how to 
> do it, but I would like to hear if any one finds problems with them or even a 
> better one.
> 
> The option one as I said yesterday (and my preferred one) would be to store 
> all the Events that have the ID (the modifications of the rule) inside the 
> "parent" event. So when querying for the event you will get only one instance 
> of it, but when you are going to access some detail, lets say the summary you 
> can specify an exact date or if you don't you get the general summary for the 
> whole recurrence. 
> 
> With this solution, some of the API of the Event has to be changed, and the 
> implementation of it. To support this embedded events (the ones changing the 
> rule). Of course the loading of the events in memory has to be changed also to 
> embedded this new Events under the parent. 
> 
> The option two would be to store the Events with ID as an independent Event. 
> This would mean that when we query the events for the next month we will need 
> to return something like QList <Event*> Each of the pointers will point to the 
> original event of the recurrence unless there is a RecurrID. So it will mean 
> that it will return the "exploded" list of the recurrences with the changes 
> already applied.
> 
> This solution requires that there will be more than one element with the same 
> UID, so the QHash has to be changed to a QMultiHash. On the first solution this 
> is not needed as a new UID can be generated concatenating the RecurrID to the 
> current UID.
> 
> Of course all these changes require modification in icalformat plus the Storage 
> layers.
> 
> I am more in favor of the first solution, as I think is more elegant and keeps 
> the API very close to what it is now. If you don't ask for an specific date you 
> will always get the general rule. Of course the UI has to be adapted to this 
> change (any of the two).
> 
I agree with you.. the first solution seems better.  I like the idea of
concatenating the UID and the RecurrID too.  So, yes please try
the first solution and we'll see how that goes.

And I'm also not sure about how the UI would need to be changed yet.

> I am also curious how this will influence your work with akonadi. So please 
> express your feelings and ideas. I hope I was able to explain clear enough.
> 
I don't believe this has any impact on Akonadi.  But I'm not an expert on that.

-Allen

-- 
Allen Winter | allen at kdab.net | Software Engineer
KDAB (USA), LLC, a KDAB Group company
Tel. USA +1-866-777-KDAB(5322), Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/