Tag Configuration object draft

[Jeroen van Meeuwen (Kolab Systems)]

On 2014-06-20 12:00, Aleksander Machniak wrote:
> On 06/20/2014 11:35 AM, Jeroen van Meeuwen (Kolab Systems) wrote:
>> I suppose that to circumvent the dead links when the target message is
>> moved/deleted, folder renamed/deleted, or any such intermediate event
>> takes place, we could add additional parameters -- perhaps in the XML,
>> perhaps in the IMAP URI.
> 
> So, what's your opinion about the format I proposed?
> 

Well, I was considering that an IMAP URI is either a direct reference 
(UID=1234), or a search (HEADER=BLAH).

Perhaps we should not squeeze them both in to the same URI and let the 
application separate truth from fiction, but instead supply both 
individual items separately.

>> As to using or not using UIDVALIDITY, I suppose ultimately this might
>> have to do with performance.
> 
> Cyrus (and Dovecot) use constant UIDVALIDITY, no? That's why I proposed
> to skip it.
> 

Yes, but UIDVALIDITY is a CONDSTORE item -- the same folder in the same 
path having been reconstructed for example would get a new UIDVALIDTY 
not to indicate it is another folder, but to allow the client to 
determine that any prior knowledge of MODSEQ / QRESYNC is obsolete.

That said, wrt. whether or not it is included in the IMAP URI used to 
refer to a message; The only scenario I can think of making it 
worthwhile to include the UIDVALIDITY transcribes as follows:

   - Create folder Foo
   - Append message Foo/1.
   - Create folder Bar
   - Append message Bar/1.
   - Link Foo/1. and Bar/1.
   - Delete folder Foo
   - Create folder Foo
   - Append another message Foo/1.

>> Suppose I link to a message Foo/1., and I find Foo/ is still the exact
>> same folder, but 1. is not in there -- I should start searching
>> (probably all folders but Foo/). If Foo/ however is a different folder
>> (the old Foo/ was renamed/deleted, a new Foo/ was created?) -- I 
>> should
>> start searching (probably all folders including Foo/) -- could I start
>> searching for whatever Foo/ may have been renamed to in a ditch 
>> attempt
>> to be a little more efficient?
> 
> So, you're proposing to use folder unique identifiers instead of names?
> It would improve performance of cases when folder is renamed, but isn't
> it a rare case? Mapping UID to name will be an additional overhead for
> any operation on relation members.
> 

No, I'm not proposing to use folder unique identifiers, I was just 
thinking out loud on whether more accurately identifying the folder 
(rather than just the path) could help performance (i.e. when including 
a persistent folder identifier, especially when a folder is renamed, if 
should be relatively quick to find the new folder location rather than 
to search all folders).

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08