Hi,
(inline reply)
Aaron Stone wrote:
My delivery code, once we got the major issues worked out, was small and
readable (with a notable exception being my % stupidity). But it triggered
some major problems elsewhere with line endings and binary safety.
Changing the line endings and replacing nuls with spaces would have been
pretty easy and still maintained the small and elegant mantra. Don't get me
wrong, though -- I'm not starting a nerd-wang fight with Ilja about whose code
gets used -- replacing my code that was too small to be useful with something
that worked and isn't much bigger is fine with me. I think that what we have
right now is a huge step forward in making things work but a huge step
backward in keeping things readable and reusable.
How is the current code backward? This is not a flame, or anything, I'd
just like to know.. I was under the impression that the newest code is
almost a simple and effective as it can get:
1. Read messages into string using fread() for a piped message, fgets()
for LMTP (replacing \r\n with \n along the way)
2. Split message
3. put it into db
how can that possibly be non-readable?
This sounds really cool. Would it actually provide an entirely new structure
for the code? If it really makes things smaller and more readable, then we
need it. If it just makes things OO buzzword compliant... not so useful.
I don't really know about gobject. I should take a good look at it. I've
mostly used glib as a safe enhancement to C. It takes perfect care of
memory management etc. It makes C just a bit less low-level, which,
IMHO, is a good thing.
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.
hmm, I haven't really formed an opinion on this yet.
I like using glib. The only thing that's holding me back at this very
moment is the fact that glib in Debian stable is still at version 1.2,
and gmime is at a very old version.
This definitely contributes to the dependency hell. Is there a consistent
subset of glib 2 that is source compatible with glib 1? Does that even matter,
as GMIME 2 requires GLib 2...
This is an important issue. Note however, that glib2 is standard on
almost all Linux distributions (Debian stable being an exception),
FreeBSD (ports) etc.
For us, it's very important that the libraries that are obligatory (at
the moment: mysql or postgresql client libraries) are in Debian stable,
because that's what we use on (almost) all our servers.
Agreed, that makes a lot of sense. Alternatively, we can use smaller
purpose-built libraries and simply include them into the source tree. Making
sure to roll in the latest updates to an in-tree library is no more difficult
than keeping track of changes in an external library, except that you're in
control of when an update breaks on you.
But this means you have quite a lot of code to maintain. It's not like
glib or gmime, or whatever other library is going to change it's API all
of a sudden.
This may be true, but glib is practically a dialect of C all to itself. They
even use a typecast for the plain pointer! (typedef void * gpointer).
This last thing is not really an issue IMHO.
Ilja
