Mailing List Archive

I've done some libtool work before, and am planning on working towards making
the database and auth providers modular during the next development cycle.
Somehow I suspect that these are not the layers that you're thinking about
tying to Python, however :-P Would you want to tap the functionality of just
the midlevel db.c? Or also have the header, mime, misc, sort functions?

At the moment DBMail really isn't layered enough to do this. We certainly
could also work on splitting up the layers with clearer specifications, but
this also limits our flexibility. Just in the past two weeks, I've rebuilt a
number of core delivery functions around better understandings of message size
and rfc size and added an entirely new data structure for handling deliveries.
With bingings to Python, etc, tapping directly into this middle layer, it
becomes immutable except between major releases...

There's also the point of view that key components should not be rewritten in
the weeks before a release rather than making what we got just work... but
IMHO breaking things quickly and fixing them well is always better than
hacking to keep within an obsolete spec, except when that spec is frozen (such
as interfaces to key libraries, and believe me, this drives library people
batty when they think about how they could make just a little change to
improve everything for themselves and downstream consumers of the library!)

Aaron


Paul J Stevens <paul@nfg.nl> said:

>
> I remember reading about someone modifying the automake/autoconf setup
> to produce shared libs with libtool.
>
> I would love to see this happen. Reason is I would like to start working
> on a python-dbmail module.
>
> --
> ________________________________________________________________
> Paul Stevens mailto:paul@nfg.nl
> NET FACILITIES GROUP PGP: finger paul@nfg.nl
> The Netherlands________________________________http://www.nfg.nl
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
--

Aaron Stone wrote:

>I've done some libtool work before, and am planning on working towards making
>the database and auth providers modular during the next development cycle.
>Somehow I suspect that these are not the layers that you're thinking about
>tying to Python, however :-P Would you want to tap the functionality of just
>the midlevel db.c? Or also have the header, mime, misc, sort functions?
>
>
>
For now I'm just thinking about exporting the db api to python. What I
want to be able to do initially is built a set of maintenance classes in
python. So I'm not concerned about the delivery chain.

>At the moment DBMail really isn't layered enough to do this. We certainly
>could also work on splitting up the layers with clearer specifications, but
>this also limits our flexibility. Just in the past two weeks, I've rebuilt a
>number of core delivery functions around better understandings of message size
>and rfc size and added an entirely new data structure for handling deliveries.
>With bingings to Python, etc, tapping directly into this middle layer, it
>becomes immutable except between major releases...
>
>
Mmm, personally I dont really believe that clearer specification,
cleaner apis, or for that matter better data-hiding, encapsulation and
general desing would make for less flexibility. But the api would indeed
have to be frozen between major releases. However, isn't that what the
difference between major and minor releases is all about?

>There's also the point of view that key components should not be rewritten in
>the weeks before a release rather than making what we got just work...
>
Hear, hear. I'm not talking about a module for 2.0. Rather 2.4 or later,
depending on how the api is fleshed out, the build system is cleaned up,
and the development cycle is defined by Ilja and Roel.

>but
>IMHO breaking things quickly and fixing them well is always better than
>hacking to keep within an obsolete spec, except when that spec is frozen (such
>as interfaces to key libraries, and believe me, this drives library people
>batty when they think about how they could make just a little change to
>improve everything for themselves and downstream consumers of the library!)
>
>
>
I couldn't agree more with you. Cleanups should not be avoided. I'm not
fluent enough in C yet to give it a serious go, but I do have more than
enough experience in refactoring old and poorly designed code to
recognize code that is in serious need of a good spring cleaning.


>Aaron
>
>
>Paul J Stevens <paul@nfg.nl> said:
>
>
>
>>I remember reading about someone modifying the automake/autoconf setup
>>to produce shared libs with libtool.
>>
>>I would love to see this happen. Reason is I would like to start working
>>on a python-dbmail module.
>>
>>--
>> ________________________________________________________________
>> Paul Stevens mailto:paul@nfg.nl
>> NET FACILITIES GROUP PGP: finger paul@nfg.nl
>> The Netherlands________________________________http://www.nfg.nl
>>_______________________________________________
>>Dbmail-dev mailing list
>>Dbmail-dev@dbmail.org
>>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>>
>>

--
________________________________________________________________
Paul Stevens paul@nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands_______________________________________www.nfg.nl