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;
};
> > 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 :-)
> >
> > 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:
> > dbmail-object.h
> > dbmail-user.h
> > dbmail-message.h
> > dbmail-server.h
> >
> > 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?
> [snip]
>
> >>> The GMime version in Woody (current Debian stable), is very obsolete
> >>> (from what I've seen). But.. The new stable is supposed to be
> >>> released this year, isn't it?
> >>
> > Yeah. So they said last september as well.... don't hold your breath.
> > I run debian/testing on many if not most of my production systems. I
> > only keep stable around on a UML image for backporting dbmail :-)
> >
> Mailutils provides a very nice message parser. Since its very complete,
> maybe we should take a look at it?
--
