An interesting problem came up during a recent bit of Kolab server-side work: tracking the lifetime of objects in the IMAP store. How hard can it be, right? In my experience, it is the deep, dark holes which start with that question. ;)
In our case, the IMAP server keeps objects (e.g. emails, events, whatever) in directories that appear as folders to the client. It keeps each object in a separate file, so each object gets a unique filename in that folder. That file name plus the folder path is unique at that point in time, something enforced by the filesystem. Let's call this the "object id" or OID for short. Of course, when you move an object from one folder to another that id changes; in fact, the file name may also change and so the OID is not constant over time. We can track those changes, however.
Inside the file is the message content of the object. There is an ID there as well, and generally those are unique to a given user. Let's call this the "message id", or MID for short. However, it is possible to share messages with others, such as when sending a calendar invitation around between users. This can lead to situations quite easily where multiple users have a message with the same MID. They of course have different OIDs .. right?
Well, yes, but only at a given point in time. It is possible that over time, with "clever" moving of objects between folders, particularly once we add in the concept of shared folders (which is the same as saying shared calendars, notes, etc.), it is possible that at different points in time there can be objects with the same OID and the same MID but which are actually physically different things.
Now if we want to get the history for a given object in the IMAP storage and list all the things relevant to it in an entirely deterministic way, how can we guarantee proper results? In a simple logging model one might want to simply key change events with the OID, MID or some combination, but since those are not guaranteed to be unique over time in any combination this leaves a small challenge on the table to make it deterministic.