Aaron Stone wrote:
I'm a huge fan of returning int's as status codes and using arguments to pass
any pointers going into or coming out of a function. Note that in these
prototypes, the length is just as important as the string and so having them
on opposite sides of the function call is, IMHO, confusing.
Personally I'm a big fan of the OO style used in libs like GLib, GMime, etc.
Always returning ints may look like a nice and clean policy, but it will
keep us from moving to a code base that will facilitate clean data
encapsulation and simple code reuse.
If we could start treating dbmail from a Model-View-Controller paradigm
(read Database, Message, Application) with *clean* interfaces the
long-term maintainability and hence viability of dbmail would become a
much more realistic possibility.
But maybe that is more something for the dbmail-3.0 timeline:
- dbmail's mission and design must be clearly defined, well documented,
crisp and on par with the best of breed open-source libraries and
applications out there.
- dbmail's performance, stability and reliability must be unsurpassed in
order to make dbmail a real contender in the field of email storage servers.
- all this and more should make it fun and easy to code in, for and on
top of dbmail.
just my 2cts.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
