On Thursday 02 December 2010 18:29:14 ext Patrick Ohly wrote: > On Do, 2010-12-02 at 14:27 +0000, Álvaro Manera wrote: > > Yes, right now the uniqueness has to be UID+RecurrenceID. So as you say > > you cannot have the same UID in to notebooks at the same time. And that > > was the original design yes. > > > > I don't understand the use case of the conflict, but you will have that > > if you have the same UID only. Which if using uuid is unlikely but > > possible yes. > > How can you mirror two remote calendars on a MeeGo device then? The > device has no control over the UID used by say, Yahoo and Google, so if > the same meeting invitation is processed by both servers, then the UID > will be the same, leading to a conflict on the device.
In that case there will be yes :) > > > Not even using different db would solve the problem. Internally the uid > > are used in hashs, so if you use more than one storage with one calendar > > you will have the same problem still. > > Where are these hashes stored, if not in the calendar's .db file? There are not stored, when I said hash I was thinking of hashtable, that is how the events are in memory. (in the calendar object) so you must have them there also separated. > > > The uid could be change to somthing like u...@nbuid but the problem is > > that the @nbui could not be shown outside the storage. Because a client > > might expect a specific id and the NB should be "transparent". > > Renaming the UID is bad, it breaks meeting invitation handling. A local > client of mKCal should see the original UID, not something created > locally to work around storage constraints. > Then in that we agree. _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
