james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger ...@joachim-draeger.de>
Subject Re: [jira] Updated: (JAMES-502) IMAP support
Date Fri, 07 Jul 2006 06:57:30 GMT
Hi Bernd,

Am Mittwoch, den 05.07.2006, 17:00 +0200 schrieb Bernd Fondermann:
> >>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 
> them.

Yes, but some of them have semantics to the server like \Seen could be
automatically set, new messages are \Recent, \Deleted messages will be
expunged, and \Recent and not \Seen are announced.

In the case of ACL / rights, every single right must be interpreted by
the server. There are already 9 rights proposed by IMAP ACL (RFC 2086).
There should be rights added for quota etc. Okay it's very unlikely we
are consuming a 32 or 64 bit int, but thing would get unclear.

I now came to the conclusion that boolean columns, one column per
flag/right is the cleanest way. The semantic is stored in the DB because
of the column names. Mapping between sql and java is fixed in the
statement. I think it's better than interpreting strings first, like it
would be needed when using IDs of a flag or rights table.

MySQL and Horde (IMP PHP webmail) are doing it the boolean column way.

> > 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

Of course it has to be mailbox_id and uid here.

> > 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.

I've already experienced bugs in applications with that. The string
would be user entered data and there might be encoding and escaping and
a version upgrade of app or db. This could lead to the situation that db
rows can't be referenced anymore.

Joachim


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


Mime
View raw message