Tag Configuration object draft
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Fri Jun 20 12:23:43 CEST 2014
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
More information about the format
mailing list