Re: bincdrop status / Binc 1.5.x

Andreas Aardal Hanssen wrote:
> Hi, Jerry.
> 
> Thanks for your work with Binc so far. I'm actually partly working with 
> Binc at work also; we've started with a Creative Friday concept where we 
> do mostly research.
> 
> For me, the question with Binc IMAP has always been - how little can I do 
> which will give the end users the most value. Sometimes that little is a 
> lot, like redesigning the server. A good design means less hassle in the 
> future, so it's definitely worth it. But at the same time, it's also about 
> focusing on end user requests, such as (what I think are most important..) 
> i18n and fast searching with SORT/THREAD.

I agree that one should make as little as possible for the most value... 
but today binc isnt really there. Thats why I want to use C++/STL alot more.

> Comments:
> 
> - Mailbox represents a class that serves two purposes today. Firstly, it 
>   represents a selected mailbox. Secondly, it's a placeholder for generic 
>   operations on any mailbox (such as STATUS, LIST, etc.). It solves is 
>   well from a technical standpoint, because we can pool these operations 
>   into the same class and make use of polymorphism in the operators. 
>   However, I have yet to see a design (in the "real world" also) that 
>   solves this problem generally: The getStatus() function in Maildir is 
>   really a static/stateless function, but C++ doesn't have a vtable 
>   concept for statics. What we have isn't all bad, but it's just ... 
>   slightly bad.
> 
> - Depot::open(), close(), flush(); what are they for? The Depot has been 
>   designed to support iteration (list all mailboxes), subscribing and 
>   selecting mailboxes. Maybe you just added those conceptually :-). 
>   Ideally, I would use the Depot class as I would any other abstraction 
>   for a directory, except that this class is tailored for IMAP folder 
>   structures. open() and so on makes it look like a file, message or 
>   something..
> 
> - Maildir is a mailbox format btw, and Maildir++ is a depot. That's why 
>   the existing classes MaildirPPDepot and IMAPdirDepot inherit Depot, and 
>   Maildir inherits Mailbox. Hmm... and I find it confusing how 
>   Maildir::Mailbox inherits Mailbox. Do we really need nested classes like 
>   this? I found it reasonable to put iterator into Depot and Mailbox, but 
>   having a nested class inherit its parent? hmmmm ... ;-)

The problem with today API is that its very statically orianted around 
Maildir format and filesystem.

The Depot class should be the class handling a depot (doh!) and 
delivering a Mailbox class. In Maildir++ those Mailboxes would be named 
INBOX INBOX.subfolder etc and in IMAPdir INBOX/ INBOX/subfolder. There 
should never be functions like filenameToMailbox etc because that only 
consentrats on a filesystem.
A Mailbox should later deliver Message objects that are based on an ID, 
beging the filename or the IMAP UID isnt what matters, it should only be 
an unique identifier.

The point of sliming down the API to this is to make it workable in 
situations as bincdrop where printing the header isnt importent or 
having a selected mailbox.

The open() close() flush() is just a common name of opening closeing and 
flushing changes to all the objects that I saw fitting to use.

The Maildir::Mailbox is just wrong =) I dont have a good way of explaing 
that in C++ but I would like to se each type of Depot (being Maildir++ 
or IMAPdir or mbox whatever) in its own namespace.

> - I've tried very hard to find a good MIME API. Or rather, an API that 
>   lets me work with MIME without loading it all into memory. Actually, the 
>   first versions of Binc IMAP used gmime ;-). I did what I could to _not_ 
>   write a MIME parser myself.
>   
>   http://spruce.sourceforge.net/gmime/
> 
>   <prejudice mode>I very often find projects that start with a G to be 
>   over engineered, very theoretically/academically built and extremely 
>   hard/painful to use in a real world application. Although I do admit to 
>   asking Mr. Stallman about dubbing Binc IMAP GNU, I'm glad today that he 
>   declined.</prejudice mode>
> 
>   Luckily, Binc 1.3's MIME parser seems to be the fastest one available. 
>   The one in 1.3 is about 20% faster than in 1.2 if I recall correctly. 
>   One of the biggest reasons for this is that we don't always read all 
>   data twice to ensure that the length prefix is correct ;-). Anyway, 
>   that's off the point.
> 
>   The problem with defining a streaming interface for MIME access has so 
>   far been that I end up with more code (and more complex code) than what 
>   we have already. I mean - what we have isn't very good from a general 
>   perspective; it's not an excellent API. But at least it's straight 
>   forward and right to the point, considering how this has been hand 
>   written for an IMAP server and all. I'm sure it can be done better, and 
>   I would like to spend some quality time going over it again. Any ideas 
>   you may have are appreciated. Hand tailored is a very important point.
>   An IMAP server is expected to:
> 
>   a) Quickly parse and search the toplevel headers.
>   b) Parse the entire document and keep a record of its structure, the
>      headers in all parts and what offsets all parts can be found.
>      Also the size and length in lines of each part of each message.
>   c) Determine the size (converted to CRLF) of the document.
>   d) Search toplevel headers, the "text" parts of the message and the
>      entire message.
>   e) Print any part or all parts of the whole document. And keeping in
>      mind that _any_ combination of any request has to be exactly
>      identical to any other combination requests that add up to the
>      same response, and it all has to add up to the reported structure
>      and total size of the document. To put it simple, if the server
>      claims that part 1.2 contains three subparts, but printing part
>      1.2 reveals only two, or four, then clients go bananas.
> 
>   This is what Binc does today, and it does it quite fast and I/O
>   efficiently. But the API could be better ;-) hehe.

I am not saying we should change the mime parsing code, I just want to 
use C++/STL streams to transport the data and not be filebased.

If the API was using streams it would be possible to move mail from one 
type of depot to another without much code because the sending depot 
delivers a stream that you can just put into the receveing depot.

I really don't think there is alot of work to be done to make the API 
very object orianted and usable in alot other applications and im 
willing to do most part of the work but there must be a new API that 
everyone can agree on.

-- 
Jerry Lundström
Sektionen för IT och media, Stockholms universitet
+46 (0)8 16 19 99 / http://www.it.su.se