Hi,
inline we go..
Aaron Stone wrote:
Doing the double reply thing again...
Dan Weber <[EMAIL PROTECTED]> said:
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.
True.
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.
Indeed. It's more a question of: Where do we want to go? (that reminds
me of some other slogan... ;) )
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 ;-)
I'd like to do the same thing. Then we can also move all database
drivers to a subtree etc. I'm experimenting with subversion for a
smaller project at the moment, to get the feel for it, and to find any
issues. Until now, it's been very simple, straightforward, and effective.
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.
I don't think DBMail is anywhere near complicated enough for us to spend
any time on UML modeling it. Everybody is free to disagree of course :)
<snip>
Ilja
