[OTR-dev] otrproxy and packaging
ian at cypherpunks.ca
Sat Jan 15 10:47:32 EST 2005
Some exciting news. We've got an AIM proxy that speaks OTR. It works
on Linux (and probably other *nixes), OSX, and we even got it to work
under wine with mingw (though it has not yet been tested on a "real"
There's no UI at all on it yet, though. [Well, it prints things to
stdout.] Which means you start OTR conversations by typing "?OTR?" in
your conversation window, and there's no way right now to leave private
mode. It also always accepts new fingerprints, since there's no way to
ask you. (It does *tell* you on stdout, though.)
In order to implement this, a lot of the "logic" code from gaim-otr was
refactored into libotr, with UI callbacks, as Evan wanted done for
Adium X anyway.
So there will soon be a 1.0.3 of gaim-otr, which uses the new refactored
library. It's got this Changelog:
> - Generate private keys automatically, if needed. Show a Please Wait
> dialog while this is happening.
> - We may as well try to use the "tag" method of checking for OTR, even
> when we don't already know a fingerprint for the correspondent.
> - Add version checking to the otrl_init() call.
> - Refactored the logic parts of gaim-otr into libotr, so they can be
> shared by other libotr-enabled apps.
But now it seems to be the time that we need to split libotr from
gaim-otr. Here's what I propose; please comment.
- libotr and gaim-otr each get the new version 1.0.3, but from now on,
their changes are independent, and will have separate version numbers.
- The version numbers for libotr from now on will follow the usual
convention: major number changes denote non-backwards-compatible API
changes, minor number changes denote backwards-compatible API changes,
sub number changes denote implementation changes, but no API changes.
- They'll need to be packaged separately now. Maybe something like this:
Contains the toolkit binaries, and possibly eventually libotr.so
Depends on libgcrypt
Contains libotr.a and the .h files (in /usr/include/libotr/)
Depends on libotr, libgcrypt-dev
Depends on libotr, glib, gtk+, gaim
Depends on libotr
- While this seems like the "right" way to do it, it means that people
downloading gaim-otr will now have to download the libotr package
separately. On some systems, package management will eventually do
this automatically (once everything makes its way to the official
distributions), but I don't know how this works on, say, OSX.
What do people think?
More information about the OTR-dev