Re: New mailbox interface and gmime messages

[Carlos Morgado <chbm chbm nu>]

On Sat, 01 Mar 2003 12:24:28 Bart Visscher wrote:
> 

> > 
> > it goes pretty much like this, you scan the mailbox and that gets you a
> > list
> > of messages. gmime Message includes from, recipients, subject and date.
> > you can also get arbitrary headers from an hash gmime creates while it's
> > scanning the message, we can cache those we need for threading.
> 
> You can just let gmime cache the headers, it is already doing that. But 
> don't think about how to implement it, think about what you want to do 
> with it.
> 

gmime keeps an hash table of such header, we may want to copy the
headers used for threading somewhere else to avoid the penalty of 
accessing the hash - but that's details

> > at this moment i'm not sure if we should have libbalsa_message_get_header
> > specific function or if we should just go ahead and peek at gmime
> > structures - much like we do with libmutt now at some points.
> > i'm pending towards macros such as
> > SUBJECT(message)
> > this can be expanded to message.subject or message.gmime.subject
> > or libbalsa_message_get_subject - whatever we need now or in the
> > future.
> 
> You can always name the macro libbalsa_message_get_subject...

that's confusing both in naming and purpose as it will expand to the
structure itself, not return a pointer to a member of the structure

> 
> > please note you always have to scan the full header while reading
> > in the mailbox so you get all the headers for free. the access penalty
> > for local stores or even nfs is negligable
> > in the imap case you can ask the server for specific headers, or
> > read in the header in bulk - which is better, depends :)
> 
> The local case is easy, just use lots of memory and cpu :-)
> I was thinking about the imap case, you could get a selected set of the 
> headers with, for example, the FETCH command. So when doing threading you 
> first fetch all the 'message-id', 'references' and 'in-reply-to' headers, 
> use that to build a threaded tree, and than fetch only for the messages in 
> view the 'subject', 'date', etc headers.

keep in mind with some server conditions that may be much slower than
geting the full header, that's why I said "depends". but yeah, in
general geting specific headers from the server is better. 
also, subject and date are also used in sorting/threading

(what pawel said about server side threading), if the server is so
lame it can't thread/sort you probably don't want to ask it to parse
headers either

> So if you want to minimize the bandwidth used for imap you should request 
> the absolute minimum at the display part. How the mailbox and message part 
> handles it, is not the consern of the display part, it should just ask the 
> message/mailbox where you can do a lot of smart things.
> 

minimizing bandwith has impact on gui responsiveness (pawel and others
already discussed that on this list and mutt-dev) and if we take that
path we *must* do prefetching.
a wicked idea just jumped me - let the user specify the cost of the
server and use that to throtle how quick we prefetch :)

the TreeStore will have to be tightly coupled with libbalsa most
smarts will reside in that interface as if we use placeholders 
for incomplete message data they will have to be mocked by
the TreeStore (errmm .. right ? :)

-- 
Carlos Morgado - chbm(at)chbm(dot)nu - http://chbm.nu/ -- gpgkey: 0x1FC57F0A 
http://wwwkeys.pgp.net/ FP:0A27 35D3 C448 3641 0573 6876 2A37 4BB2 1FC5 7F0A