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-560569332-1124121412=:6656
Content-Type: TEXT/PLAIN; charset=UTF-8
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Mon, 8 Aug 2005, Jerry Lundstr=C3=B6m wrote:
> 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.

The STL is not a solution to any design problems; it's simply a set of=20
template classes. It's very important not to over engineer here. I don't=20
think the std streams (in particular) are any good at all. Especially=20
considering how poor support there is for modern STL/std classes in older=
=20
compilers.

> The problem with today API is that its very statically orianted around=20
> Maildir format and filesystem.
> The Depot class should be the class handling a depot (doh!) and=20

What do you mean with the "doh!"? Please explain.

> delivering a Mailbox class. In Maildir++ those Mailboxes would be named=
=20
> INBOX INBOX.subfolder etc and in IMAPdir INBOX/ INBOX/subfolder. There=20
> should never be functions like filenameToMailbox etc because that only=20
> consentrats on a filesystem.

The Depot is an abstraction for storing an IMAP mailstructure on the file=
=20
system. It works splendidly in that sense, and there's no reason to design=
=20
it to do anything else. It already acts as the authority for creating=20
Mailbox objects and everything that has to deal with mailboxes. Of course=
=20
the filenameToMailbox functions could be designed differently, but the=20
only reason for totally changing them would be if Depot should start=20
supporting depot types that are not file based, and there are no such=20
depots today. I do not design software to support what <10% of our users=20
will use actively.

> A Mailbox should later deliver Message objects that are based on an ID,=
=20
> beging the filename or the IMAP UID isnt what matters, it should only be=
=20
> an unique identifier.

I seriously don't understand what the difference is between a UID and a=20
unique identifier. Please elaborate how this is different from today's=20
approach.

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

I'm sorry, but I don't quite understand how today's API, which allows you=
=20
to search and print any part of all headers in any message, prevents=20
bincdrop from printing the header... Store the message on disk, use=20
today's API, and voila.

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

Well I just found them confusing ;-). Mailboxes are selected and closed,=20
and depots are iterated over.

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

There's no need to use namespaces like that in Binc; we already have=20
classes that group the concepts together. Nesting classes is in general a=
=20
very confusing design pattern that applies only to a very limited set of=20
programming languages. So I think we should avoid that.

>> 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=20
> 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=
=20
> type of depot to another without much code because the sending depot=20
> 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=20
> very object orianted and usable in alot other applications and im=20
> willing to do most part of the work but there must be a new API that=20
> everyone can agree on.

OK, but please don't do anything yet. Firstly, Binc IMAP is designed to=20
use file system based Depots, but mailboxes can be of any type. That=20
simplifies the design radically, and is one of the main reasons for why=20
Binc is fast. Don't pass all data through streams before doing performance=
=20
measures that show that we're as fast as today. I speeded up the MIME=20
parser in 1.3 to make us even faster than 1.2; not to compensate for=20
degraded performance due to the introduction of std streams.

For Binc 1.3, we have two main goals and several smaller ones. The main=20
goals are i18n and SORT/THREAD, and one of the big smaller goals is=20
indexing. I understand that bincdrop could make use of a different API,=20
but bincdrop is a separate tool, and it doesn't need Binc IMAP to operate.=
=20
And what I'm trying to say is that Binc IMAP should not _necessarily_=20
change because of bincdrop. If you need to change what works fine today to=
=20
make bincdrop work, then maybe bincdrop should change instead.

All our major feature requests for 1.3 can be implemented without changing=
=20
the design of the server radically. When I'm talking moderate API=20
redesign, I'm all for refactoring the API to make it easier to work with=20
and easier to maintain and extend. But I really don't see the value in=20
doing it all differently at this point. And in particular, I don't see the
value of introducing streams.

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-560569332-1124121412=:6656--