headers
Timo Sirainen | 13 Feb 2012 01:45
Picon
Picon
Favicon

ANNOTATE-EXPERIMENT-1


I was thinking about finally implementing METADATA + per-mail annotations to Dovecot so I read through the
RFCs. There are mainly two things I'd do differently in ANNOTATE-EXPERIMENT-2:

1. METADATA has case-insensitive entry names, ANNOTATE has case-sensitive. Probably better to keep them
case-insensitive in both.

2. SORT (ANNOTATION) - is this really worth the trouble? There's really no good way for servers to implement
this in an efficient way. It would pretty much require building and maintaining an index for every single
annotation entry name.

And other things I wondered about:

 - If APPEND has annotations, and annotation limits are reached, the whole APPEND fails with
TOOBIG/TOOMANY error? I guess it has to, although that's a bit annoying.

 - ANNOTATE doesn't specify what happens if STORE can change only some of the entries. Should it rollback the
changes to all the previous entries as well? Including changes to previous messages if multiple messages
were specified? Would have been simpler if both METADATA and ANNOTATE supported changing only one
annotation at a time.

 - TOOBIG/TOOMANY doesn't map very nicely if I want to have global "max. annotation size" and "max.
annotation count". Perhaps a global max. count shouldn't exist, since the number of mails/mailboxes
could be limited instead, but a global size similar to mail quota should exist. I guess when that global
size is reached it just fails with TOOBIG until some annotations are deleted.
Permalink | Reply |
headers
Arnt Gulbrandsen | 13 Feb 2012 10:19
Picon
Favicon
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On 02/13/2012 01:45 AM, Timo Sirainen wrote:
> 
> I was thinking about finally implementing METADATA + per-mail annotations to Dovecot so I read through
the RFCs. There are mainly two things I'd do differently in ANNOTATE-EXPERIMENT-2:
> 
> 1. METADATA has case-insensitive entry names, ANNOTATE has case-sensitive. Probably better to keep
them case-insensitive in both.

I wouldn't mind.

> 2. SORT (ANNOTATION) - is this really worth the trouble? There's really no good way for servers to
implement this in an efficient way. It would pretty much require building and maintaining an index for
every single annotation entry name.

Sorting at read time isn't bad, considering the very low number of
annotations used.

But I don't mind dropping that in the least. AFAIK noone has actually
wanted to sort by an annotation.

> And other things I wondered about:
> 
>  - If APPEND has annotations, and annotation limits are reached, the whole APPEND fails with
TOOBIG/TOOMANY error? I guess it has to, although that's a bit annoying.

Append is transactional. I agree it can be annoying sometimes, such as
when ten-thousand-message multiappends break. But IMAP already has
enough funny little exceptions, please don't try to add a rule such as
"append is transactional except in regard to annotations".
(Continue reading)

Permalink | Reply |
headers
Bron Gondwana | 13 Feb 2012 10:32
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On Mon, Feb 13, 2012, at 10:19 AM, Arnt Gulbrandsen wrote:
> 
> On 02/13/2012 01:45 AM, Timo Sirainen wrote:
> > 
> > I was thinking about finally implementing METADATA + per-mail annotations to Dovecot so I read through
the RFCs. There are mainly two things I'd do differently in ANNOTATE-EXPERIMENT-2:
> > 
> > 1. METADATA has case-insensitive entry names, ANNOTATE has case-sensitive. Probably better to keep
them case-insensitive in both.
> 
> I wouldn't mind.

Keywords are already case insensitive.  Which is going to be a pig in poke if we try to make UTF8 keywords.

> > 2. SORT (ANNOTATION) - is this really worth the trouble? There's really no good way for servers to
implement this in an efficient way. It would pretty much require building and maintaining an index for
every single annotation entry name.
> 
> Sorting at read time isn't bad, considering the very low number of
> annotations used.
> 
> But I don't mind dropping that in the least. AFAIK noone has actually
> wanted to sort by an annotation.

If nobody wants it, it doesn't matter if it's inefficient, right?

If people do want it, then you can track the annotations they are actually
using to sort by and index those... at least that's the theory behind having
adaptive indexing.
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 13 Feb 2012 10:49
Picon
Favicon
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On 02/13/2012 10:32 AM, Bron Gondwana wrote:
> Keywords are already case insensitive.  Which is going to be a pig in poke if we try to make UTF8 keywords.

Unicode case insensitivity isn't so bad.

One rule for Turkish, one rule of the rest of the world, and anyone who
can define i to be equal to ı can sidestep the difference. In IMAP's
case, these two commands could be defined to be equivalent:

  a store +flags 1 istanbul
  b store +flags 1 ıstanbul

Not pretty but also not the end of the world.

(Neat: This spell checker, which I must find out how to turn off btw,
thinks istanbul is wrong and ıstanbul right.)

>> But I don't mind dropping that in the least. AFAIK noone has actually
>> wanted to sort by an annotation.
> 
> If nobody wants it, it doesn't matter if it's inefficient, right?

Mostly, but not quite.

A fetch item that noone ever calls can still require copy and append to
do extra work.

>> Why would store be able to change only some entries?
>
(Continue reading)

Permalink | Reply |
headers
Bron Gondwana | 13 Feb 2012 14:04
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On Mon, Feb 13, 2012, at 10:49 AM, Arnt Gulbrandsen wrote:
> On 02/13/2012 10:32 AM, Bron Gondwana wrote:
> > Keywords are already case insensitive.  Which is going to be a pig in poke if we try to make UTF8 keywords.
> 
> Unicode case insensitivity isn't so bad.
> 
> One rule for Turkish, one rule of the rest of the world, and anyone who
> can define i to be equal to ı can sidestep the difference. In IMAP's
> case, these two commands could be defined to be equivalent:
> 
>   a store +flags 1 istanbul
>   b store +flags 1 ıstanbul
> 
> Not pretty but also not the end of the world.
> 
> (Neat: This spell checker, which I must find out how to turn off btw,
> thinks istanbul is wrong and ıstanbul right.)

And of course there's normalisation as well.  I really don't know as much
about this area as I should.  I guess the obvious is "require best practice
as defined <over there>".

> >> But I don't mind dropping that in the least. AFAIK noone has actually
> >> wanted to sort by an annotation.
> > 
> > If nobody wants it, it doesn't matter if it's inefficient, right?
> 
> Mostly, but not quite.
>
(Continue reading)

Permalink | Reply |
headers
Arnt Gulbrandsen | 13 Feb 2012 14:21
Picon
Favicon
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On 02/13/2012 02:04 PM, Bron Gondwana wrote:
> And of course there's normalisation as well.

Normalisation doesn't affect meaning at all. It's just changes such as
"o umlaut-above-previous-letter" into "o-with-umlaut" or the other way.
Useful for text processing.

Arnt
Permalink | Reply |
headers
Bron Gondwana | 13 Feb 2012 14:30
Gravatar

Re: ANNOTATE-EXPERIMENT-1


On Mon, Feb 13, 2012, at 02:21 PM, Arnt Gulbrandsen wrote:
> On 02/13/2012 02:04 PM, Bron Gondwana wrote:
> > And of course there's normalisation as well.
> 
> Normalisation doesn't affect meaning at all. It's just changes such as
> "o umlaut-above-previous-letter" into "o-with-umlaut" or the other way.
> Useful for text processing.

Also useful for checking if a particular keyword is already set, and merging
the various forms together into a single keyword.

Bron.
--

-- 
  Bron Gondwana
  brong <at> fastmail.fm
Permalink | Reply |

Gmane