Need advice: mailbox-based \Seen flag

[Ken Murchison]

Ken Murchison wrote:
> Boris Lytochkin wrote:
>> Hello!
>>
>> I need an advice in implementing per-mailbox \Seen flag (or 'shared'
>> \Seen flag in per-user basis).
>>
>> For now I want to implement it this way:
>> 1) add a new mailbox attribute, say 'sharedseen'
>> 2) switch path for .seen file in imap/seen_*.c:seen_getpath() if
>>    'sharedseen' flag is set on mailbox.
>> 3) changes in replication module?
>>
>> So, setting 'sharedseen' attribute to mailbox will cause using
>> per-mailbox seen-file.
>>
>> What are weak points of this implementation?
>> Is there more correct way to make per-mailbox \Seen flag?
> 
> My quick thoughts would be the following:
> 
> - Add a 'sharedseen' mailbox attribute as you suggest (as a mailbox 
> annotation)
> 
> - When a mailbox is opened that has this annotation enabled, we open the 
> seen state database for the special 'anyone' user instead of the 
> authorized user.  This would allow using the same API with minimal 
> changes.  Perhaps we could come up with a better userid then 'anyone' 
> but its already reserved as special via ACL.
> 
> -----
> 
> - As an alternative to using a seen db for 'anyone' we could go back to 
> using a local seen db in the mailbox folder, but then we'd have to have 
> function pointers to swap between the functions for local access vs 
> per-user access.
> 
> - As another alternative, we could keep track of shared seen state in 
> cyrus.index, but that would require an upgrade to the index file format, 
> and more API changes.

I actually went digging into seen state and cyrus.index a little today 
for another reason, and I realized that we wouldn't have to 
expand/upgrade the index file to accomodate a shared seen state.  The 
existing field for system flags is just a bitmask, so we could easily 
add a bit for shared \Seen.  We could also implement the sharedseen 
annotation as a mailbox flag in the index header, just like condstore.

Based on other changes that I'm thinking about, I'm starting to like 
this idea better, even thought it *may* involve more code.


-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University