Re: [Dbmail-dev] dynamic library loading

[Dan Weber]

Aaron Stone wrote:

Doing the double reply thing again...

Dan Weber <[EMAIL PROTECTED]> said:

Paul J Stevens wrote:

Aaron Stone wrote:

We should find a suitable replacement MIME parser that provides a similar

enough interface that it can be swapped in with just a few hours work.

I guess there's no real contender: gmime.

There were a couple of other MIME libraries that I looked at. Although none
are as fully complete as gmime, we only need functionality to pick apart a

message, we don't need much decoding and we don't need to create messages.

Ilja Booij <[EMAIL PROTECTED]> said:

Paul J Stevens wrote:

Aaron Stone wrote:

I'm still skeptical about becoming dependant upon glib, so I'd prefer to see libtool's ltdl used.

I think ltdl should be used also, I listed some reasons below.

I started out by trying to figure out how gmime's parser feels. I quickly managed to write a test that would parse messages, and split the message into a header/body GString pair, and split the body into a GList of messageblks. That was real easy, and the code footprint very small.

Already we're talking about GStrings and such, which means that we're looking
at a radically different codebase. Frankly, though, all strings should be
structs that look like this, which is definitely The Right Thing (TM)...

struct GString
{
 gchar *str;
 gint len;
};

bah, I hate working with glib.

But my guess is we'll want to do more and different things as time goes by. And I like how gobject allows clean data-encapsulation. So a OO approach just feels natural to me.

I suppose... but I'm not sure how much data encapsulation we really need.
Email is fairly simple, after all -- so the encapsulation will also be simple,
and at that point I start to wonder why we'd want a simple wrapper around
something simple?

I suggest an OO approach wait till dbmail 2.1. We are in the rc cycle now, that kind of change would really hold the dbmail 2.0 release off for a while.

Obviously. This isn't the question we're trying to answer, though.

But I agree that usefullness is strictly required :-)


dbmail-object.h
dbmail-user.h
dbmail-message.h
dbmail-server.h

However, I don't see why we couldn't introduce gobject/glib interfaces incrementally. We'd introduce the gobject structure in a set of new header files, for instance: These wouldn't collide with the current namespace and could therefor be implemented without breakage.

Actually, the problem with our namespace right now is that there's basically
only three namespaces: auth, sql, everything else. I'd like to suggest moving
the repository to Subversion by year's end so that we can rearrange things to
be a little more better in the subdirectory department ;-)

Dan Weber has a very good idea with making parts of DBMail available through a library interface. If we're exposing a gobject, that means

any front-end programs would also have to be written for glib. I'm OK
with it being viral in that it might be spreading good-software karma,
but I'm less comfortable with dictating how the library can be used.

From browsing through how glib's modules setup works, it doesn't support the many platforms that libtool does, and I think its not very cleanly. As I said above, an OO design should wait till dbmail 2.1, then we should implement glib and use a UML builder to get this on its feet. UML is essential to making a clean object oriented code base.

UML is buzzword compliant. It makes managers happy. It precludes real work.

Yes, to some extend. Of course it would probably preclude any takeover of dbmail by some big corporation with an allergy for gpl (think: apache re IBM, and zope/plone re CA).

But writing the library with gobject would make writing wrappers for other languages a breeze.

Swig and few shots of espresso is the best way to make wrappers :)

SWIG looks really neat. Does it work with GObjects?

SWIG is real easy, it'll work with anything as far as I know. I am trying to figure out a way to recursively grab all symbols from a library and load them into namespace using lt_dlopen(). Maybe I could get swig to spit something out.

[snip]

Mailutils provides a very nice message parser. Since its very complete, maybe we should take a look at it?

You really should take a look at the libmailutils stuff.  Very complete.

Dan Weber

signature.asc
Description: OpenPGP digital signature