grim at reaperworld.com
Mon Feb 14 15:51:35 EST 2011
On 02/14/2011 01:09 PM, Mark Doliner wrote:
> On Sun, Feb 13, 2011 at 10:59 PM, Gary Kramlich<grim at reaperworld.com> wrote:
>> I just pushed a new branch to break the hash/cipher implementations out
>> to separate files. The branch is named im.pidgin.cipher_breakout.
> What's the motivation for moving it into a separate directly and
> building it as a convenience library?
Adding ciphers isn't a fun task to begin with, even less so when you
have to jump around a 3000+ line file. The convenience library was
built to get the source files out of the main purple source directory.
There's enough going on there that we don't need to add 8 new source
files to it.
>> Registering ciphers is similar to before, but instead of registering
>> with the address of the ops struct which is static to cipher.c, you now
>> call a non-static function in the sub-library. To do this, you need to
>> add a prototype above the register function (you'll see it).
> Hmm, does this change libpurple's public API? Or is it ok because the
> convenience library gets included in libpurple itself? In any case,
> if you're exposing purple_g_checksum_* then this probably shouldn't go
> into im.pidgin.pidgin, but rather im.pidgin.pidgin.next.minor.
> Although, I think we should probably put underscores in front of the
> purple_g_checksum_* functions and mark them as deprecated and warn
> people away from using them. Or maybe only expose the headers #ifdef
There are no changes to public api, just additions. We will not be
removing the purple_g_checksum_* api since it's used for the
PurpleCipher wrapper around GChecksum which was introduced in glib
2.16.0. If we're compiling against glib < 2.16.0 these functions are
The registration functions have prototypes in cipher.c so it compiles
clean and the actual symbols are resolved during link time when
libpurple-ciphers.la is linked.
Gary Kramlich <grim at reaperworld.com>
More information about the Devel