notmuch as a shared object aka library knigge

[Justus Winter]

Quoting Justus Winter (2012-02-22 16:17:45)
>Quoting Austin Clements (2012-02-21 16:53:12)
>>As always, patches welcome!
>
>Well, hacking on c code in my free time is not my idea of fun and I'm
>not familiar with the code base, so I'd appreciate it if someone who
>is in a better position to whip up a patch would step up and do so.

That wasn't meant to sound as harsh as it probably did. I seriously
hope that someone is around who enjoys to hack on the c/c++ part of
the library and is willing fix problems in it.

I've got a lot of ideas how to improve the python bindings and have
been refactoring it in the past few days. And while doing so I came
across a few problems in the library, one of which was so easy to fix
that I did just that.

And I worked around the two functions (that I know of) that call
exit(3) by conditionally raising exceptions in the python bindings,
but this is only meant as a intermediate fix, a hack that should be
removed as soon as the library is fixed.

But most of those problems require api changes and some kind of idea
on how to do this in a consistent and extensible way while hopefully
providing a smooth transition to the new api. And I don't feel that
I'm in a good position to do this (I know next to nothing about symbol
versions and linker magic) so I mentioned the problems and asked for
help on this issue.

Btw, I think that we can keep the python api stable even if we change
the underlying library. So if there isn't actually anyone who directly
links against libnotmuch (maybe the mutt fork does?) we may not even
worry so much about api stability of libnotmuch.

Happy hacking,
Justus