On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
Am Mittwoch, den 10.01.2007, 17:53 +0000 schrieb robert burrell donkin: > On 1/10/07, Joachim Draeger <[EMAIL PROTECTED]> wrote:
<snip>
> clients are typically interested only in a subset of the headers Right. For current implementation: I already split the headers up in single rows for this purpose. (And for efficient searching) Unfortunately the current FetchCommand implementation always examines the whole MimeMessage. I'm going to fix this first and than provide a way to query a header subset.
sounds good
> think about this from the perspective of meta-data. when using a RDBMS > for storage, it's not efficient for all meta-data to be equal. some is > much more important that others. this should be reflected in the > database structure. Could you give an example?
the X-gppmail-state header is meta-data about an email. i'm willing to be that very few clients will ever query for this data. this may as well go in the same table as all the rest of the seldom used meta-data. the from header is very frequently queried for together with ANSWERED, READ and so on. it seems obvious to me that a table contain one column for each bit of frequently used meta-data indexed against a key for the mail would allow a single, efficient query to be run for this meta-data at least.
> IMHO this optimization is best done in the storage layer Right, but you have to provide methods in the API for such requests. That's why there are so many more or less protocol aware methods. A possibility for requesting a subset of headers is still missing.
there other ways of allowing optimization than providing protocol specific methods: what important is that the storage layer is able to understand the operation fully and then choose the best way to implement it. what meta-data is likely to be frequently queried is dependent on knowledge of client behaviour, not the particular protocol. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
