cool things to do with annotations

[brong]

From: Rob Siemborski Bugzilla-Id: 1292 Version: 2.1.x Owner: Ken Murchison

[brong]

From: Rob Siemborski

[brong]

From: Rob Siemborski

Ack, hit enter too fast:

Some of these may require new mailbox metadata to be maintained

• total size of mailbox
• who created mailbox
• date of mailbox creation
• time of last mailbox update (any change of the cyrus index or header files, I guess is a good way to define this)
• time of last selection for this user?
• free space on this mailbox's partition
• number of selections in past 24 hours (unclear that this is worth the overhead, but I thought I'd throw it up here)

[brong]

From: Ken Murchison

> - time of last mailbox update (any change of the cyrus index or header files, I > guess is a good way to define this)

Would this be last update, or when then last message arrived (like fud)?

> - time of last selection for this user?

Last SELECT/EXAMINE or last read (like fud)?

[brong]

From: Rob Siemborski

I'd want this stuff to be information that is not directly available otherwise through IMAP.

So, the first one is last mailbox update (since you can just look at the most recent message if you want that information). This would also get acl changes, etc.

The second is the actual timestamp of the last select (which shouldn't require any additional information). Maybe on user mailboxes we would also offer a last select by that user (to admins anyway)

[brong]

From: Rob Siemborski

Tagging for 2.2 milestone.

[brong]

From: Rob Siemborski

another one:

• should a mailbox be squatted?

[brong]

From: Rob Siemborski

adding 1187 as dependancy

[brong]

From: Ken Murchison

committed vendor/cmu/cyrus-imapd/size implementation

[brong]

From: Rob Siemborski

committed vendor/cmu/cyrus-imapd/lastupdate implementation

[brong]

From: Rob Siemborski

no reason this should block 2.2.0

[brong]

From: Ken Murchison

another one:

• if/when should messages be expired?

[brong]

From: Rob Siemborski

2.2 now has expire support, right?

[brong]

From: Ken Murchison

yup

[brong]

From: Ken Murchison

> - who created mailbox > - date of mailbox creation

Could both of these be added to the end of cyrus.header? I could use this info for nntpd (NEWGROUPS and LIST ACTIVE.TIMES)

> - time of last selection for this user?

This could be stored as a read-only private annotation for each mailbox (each user would have their own value)

[brong]

From: Rob Siemborski

That seems to be a sane place for them, I just start to worry about the expense of searching for annotations and so on.

I guess I also worry somewhat about cluttering the mailbox metadata with annotations, which already have a home in annotate.db.

Hmmm

[brong]

From: Ken Murchison

I assumed that the creation stuff made more sense in cyrus.header because its read-only and its not per-user

[brong]

From: Ken Murchison

Of course, like you said, fetching this info for multiple mailboxes would suck. Perhaps using annotations.db would be better, eg:

/vendor/cmu/cyrus-imapd/creator

where value.shared is the person who did the CREATE/RENAME and modifiedsince.shared would be the time of creation/rename

[brong]

From: Ken Murchison

Should we go ahead and implement /creator in annotation.db?

[brong]

From: Rob Siemborski

Yes. I'm not sure what the readability should be though. Certainly not by anyone who can't list the mailbox, but it may want to be more restrictive than that? (do people really want to know who created graffiti.goat-porn ?)

[brong]

From: Ken Murchison

Certainly the 'l' right would be required, but I can't think of any other right to require other than 'r'. NNTP NEWGROUPS would only look for the modifiedsince attrib and LIST ACTIVE.TIMES would look for both.

[brong]

From: Rob Siemborski

I think we may want this to default to 'la' and have an option to restrict it less.

[brong]

From: Rob Siemborski

where "option" implies "bitmask"

[brong]

From: Ken Murchison

I'm not sure we want to give 'a' to 'anyone' just to get access to this info, do we (I'm thinking in the NNTP space)?

[brong]

From: Rob Siemborski

I'm not convinced its critical, thats why I'd provide an option to change the bit (or to allow the use of a numeric bit).

There may be more questions here than I want to address at the moment.