I think that we're beating around the bush. The MIME parser is inflexible and the code is hard to read. It's the kind of code that everyone dreads because only two guys in the office understand it and only one can effectively modify it. And that's for an easy problem.
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. 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. Inline replies to both Paul and Ilja... Aaron 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. > > > > Why are you skeptical about glib? I've been working on a OO structure > > for dbmail using gobject, glib and gmime, so if there are serious > > objections I'd like to know asap. 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. 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. > 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... > 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. > 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? > > Anyway, I think GLib can give us a nice way of making our code better > and more readable through the use of all it's various utility-functions > and structures. 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). > cheers, > Ilja > --
