james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: [jira] Updated: (JAMES-502) IMAP support
Date Wed, 05 Jul 2006 15:00:31 GMT
Joachim Draeger wrote:
> Hi Stefano,
> Am Freitag, den 30.06.2006, 13:23 +0200 schrieb Stefano Bagnara:
>>1) flag: are flags dynamic? I understand from your document that we need 
>>to store the flag types in a table so that their ID can be used. Is it 
>>needed or the flag types are statically defined in the RFC?
> I was reading RFC again carefully about this topic. Handling
> many-to-many relationships might have some drawbacks. In fact the
> predefined system flags like \Seen and \Answered can't be extended, so
> we could store them either using a binary combination or one boolean
> column per flag.
> Well, I still don't like storing externally defined constants, like
> OR-ing flags to an int value. But it might have the highest performance
> and could be quite easy to handle. What do you think?

+1 for boolean flags. I expect more serious performance bottlenecks 
elsewhere ;-)

in the RFC the flags are string constants and have no ID attached to 
them. so the implementation can choose whether or not it assigns IDs to 

> Allowing user defined flags, that are called keywords in the RFC, is an
> additional feature. (Currently milestone 5 of the roadmap draft.) IMO
> the best approach would be a one-to-many relationship here.
> Table name: "keyword"
> message_id  integer  the message this keyword is assigned to
> name        varchar  name of the keyword  
> primary key (message_id,name)
> Maybe it is not so good having a string in the primary key. In this case
> we could add an auto-increment primary and a unique index for
> (message_id,name).

as far as I can tell, having string-based PKs is ok.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message