On Wednesday 01 December 2010 15:50:43 ext Patrick Ohly wrote: > Hello! > > Let me share an observation, just in case that it is relevant for other > developers. mkcal supports multiple "notebooks" inside the same calendar > database. However, these notebooks are not as independent from each > other as one might expect: if notebook A has an event with UID=foo, then > notebook B cannot also have an event with that same UID. > > I suppose this works as intended, but it is not how other PIM storages > work. I also find it a too limiting and wonder how this feature is used. > If one notebook is say, synchronized with Google, and the other notebook > is for a local calendar, then I would get conflicts when a meeting > invitation is processed by both Google and the local app. > > The only solution that I see is to not use the "notebook" feature and > instead use separate calendar .db files. Alvaro, do I miss something? >
Hi, 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. 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. 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". It is a nice to have thing :) but should be properly thought... Alvaro _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
