Re: Summary store, impl n. 7



On Thu, 2007-12-27 at 21:00 +0100, Philip Van Hoof wrote:
> On Thu, 2007-12-27 at 20:53 +0100, Philip Van Hoof wrote:
> 
> > o. Has a way to create new items easily. Deals with out-of-order adding
> >    of items (when requesting an item with a sequence number that doesn't
> >    yet exist, you'll simply get NULL)
> 
> 
> Note:
> 
> To support what Dave's E-mail client does, and what Pine, Mulberry and
> others seem to be doing, we could also make it possible (or optional) to
> fill up gaps in the summary with dummy items that contain "..." for all
> string fields.

A similar idea had somewhat crossed my mind a while back a month or two
ago when hacking on libspruce / camel-imap4.

The summary code handles getting envelopes/rfc822.size/uid/etc from the
server out-of-order by keeping an array of temporary envelope structs;
after fetching the requested set (which is typically all of them), it
will add, in sequential order, all of the completely fetched items to
the summary up until the first incomplete item or the end of the array
(whichever comes first).

You'll also note that the code handles getting envelope/size/uid/etc in
multiple chunks, meaning the server could reply with something like
this:

* 1 UID <uid>
* 2 UID <uid> ENVELOPE <whatever>
* 2 RFC822.SIZE 12345
* 3 ...
* 4 ...
* 1 RFC822.SIZE 45678
* 5 ...
* 1 ENVELOPE <whatever>
..

The way it does this is by keeping a bit field of which information it
has received from the server.

Anyways, it got me thinking about getting rid of the temp envelope
struct array altogether and just immediately adding info to the summary
as it arrived. The problem was that in order for this to work nicely, it
would be ideal if the summary was some sort of "database" so that I
could insert records as I got them, out of order if need be.

Truth be told, I'd probably still always insert items in sequential
order, I'd just insert dummy records and/or records with a bit field
specifying which data has been populated already.

The problem with the current summary files is that they don't lend
themselves well to inserting records out of order or even changing
record sizes without rewriting the entire summary file :(

Using a db and records with a bit field representing which pieces of
info the record has would also be kinda cool if at some later date more
fields are added to a CamelMessageInfo.

Jeff




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]