Re: bincdrop status / Binc 1.5.x

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

---1538120507-389628469-1123269879=:7858
Content-Type: TEXT/PLAIN; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <[email protected]>

Hi, Jerry.

Thanks for your work with Binc so far. I'm actually partly working with=20
Binc at work also; we've started with a Creative Friday concept where we=20
do mostly research.

For me, the question with Binc IMAP has always been - how little can I do=
=20
which will give the end users the most value. Sometimes that little is a=20
lot, like redesigning the server. A good design means less hassle in the=20
future, so it's definitely worth it. But at the same time, it's also about=
=20
focusing on end user requests, such as (what I think are most important..)=
=20
i18n and fast searching with SORT/THREAD.

BTW the idea with adding a Qt 4 dependency is just one idea I've had..=20
iconv is much adapted and easier to integrate with less hassle for the=20
i18n support, and we don't need Qt for i18n support. But if we do add Qt=20
to Binc, we get a lot of good stuff for free. So far I'm giving it a=20
thumbs down just to keep my mind on the right track.

On Fri, 29 Jul 2005, Jerry Lundstr=C3=B6m wrote:
> Hi all,
> As I know been working on bincdrop for a week trying to get the=20
> functionallity to work with the binc 1.3 branch I have run into alot of=
=20
> problems. All these problems has made me start to think about a rework=20
> of the classes in Binc, especally the Depot structure to make it more=20
> object oriented and usable in other contexts then just IMAP.

This is a good idea, and 1.3 is the right place for it. These classes were=
=20
designed with one backend in mind, so adding a new use for it will=20
certainly cause design changes. I don't see this as a problem.

Please don't refer to the 1.5 version; it'll just confuse people with=20
search engines when the time for 1.5 comes. All discussion today (and=20
trunk svn) is about 1.3. ;-)

> The attached document is a work-in-progress for a suggested class layout =
of
> future version of binc.
> What I have thought about when designing the super classes is to slim the=
m down
> to the common funtions that all (that I know) depot/mailbox/message shoul=
d
> have.
> After that we can add specific functions to Maildir and suchs.
> I also think its is a very good idea that we start using STL to the fulle=
st,
> for example reading raw data from a message should be a class with the os=
tream
> as super class. How this data in the ostream has been put there isnt for =
the
> others to know, it can be a fostream or a sstream or whatever.
> As you look at the layout you will see that alot is missing but I hope th=
e
> generall idea is there.
> Also, this kind of design fits very well into a libbinc.
> Please, imagen to work with it and comment... and have a nice weekend!

Comments:

- Mailbox represents a class that serves two purposes today. Firstly, it=20
  represents a selected mailbox. Secondly, it's a placeholder for generic=
=20
  operations on any mailbox (such as STATUS, LIST, etc.). It solves is=20
  well from a technical standpoint, because we can pool these operations=20
  into the same class and make use of polymorphism in the operators.=20
  However, I have yet to see a design (in the "real world" also) that=20
  solves this problem generally: The getStatus() function in Maildir is=20
  really a static/stateless function, but C++ doesn't have a vtable=20
  concept for statics. What we have isn't all bad, but it's just ...=20
  slightly bad.

- Depot::open(), close(), flush(); what are they for? The Depot has been=20
  designed to support iteration (list all mailboxes), subscribing and=20
  selecting mailboxes. Maybe you just added those conceptually :-).=20
  Ideally, I would use the Depot class as I would any other abstraction=20
  for a directory, except that this class is tailored for IMAP folder=20
  structures. open() and so on makes it look like a file, message or=20
  something..

- Maildir is a mailbox format btw, and Maildir++ is a depot. That's why=20
  the existing classes MaildirPPDepot and IMAPdirDepot inherit Depot, and=
=20
  Maildir inherits Mailbox. Hmm... and I find it confusing how=20
  Maildir::Mailbox inherits Mailbox. Do we really need nested classes like=
=20
  this? I found it reasonable to put iterator into Depot and Mailbox, but=
=20
  having a nested class inherit its parent? hmmmm ... ;-)

- I've tried very hard to find a good MIME API. Or rather, an API that=20
  lets me work with MIME without loading it all into memory. Actually, the=
=20
  first versions of Binc IMAP used gmime ;-). I did what I could to _not_=
=20
  write a MIME parser myself.
 =20
  http://spruce.sourceforge.net/gmime/

  <prejudice mode>I very often find projects that start with a G to be=20
  over engineered, very theoretically/academically built and extremely=20
  hard/painful to use in a real world application. Although I do admit to=
=20
  asking Mr. Stallman about dubbing Binc IMAP GNU, I'm glad today that he=
=20
  declined.</prejudice mode>

  Luckily, Binc 1.3's MIME parser seems to be the fastest one available.=20
  The one in 1.3 is about 20% faster than in 1.2 if I recall correctly.=20
  One of the biggest reasons for this is that we don't always read all=20
  data twice to ensure that the length prefix is correct ;-). Anyway,=20
  that's off the point.

  The problem with defining a streaming interface for MIME access has so=20
  far been that I end up with more code (and more complex code) than what=
=20
  we have already. I mean - what we have isn't very good from a general=20
  perspective; it's not an excellent API. But at least it's straight=20
  forward and right to the point, considering how this has been hand=20
  written for an IMAP server and all. I'm sure it can be done better, and=
=20
  I would like to spend some quality time going over it again. Any ideas=20
  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.

That's what I have so far..=20

Andy :-)

--
Andreas Aardal Hanssen   | http://www.andreas.hanssen.name/gpg
Author of Binc IMAP      |  "It is better not to do something
http://www.bincimap.org/ |        than to do it poorly."
---1538120507-389628469-1123269879=:7858--