Communication between plug-ins

Daniel Kraft d at domob.eu
Sat Aug 17 13:03:29 EDT 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

I've patched the Pidgin OTR plug-in to allow verification of
fingerprints via the Namecoin identity system:

  git clone -b namecoin-verify https://git.domob.eu/pidgin-otr-nmc.git

This was however only a proof-of-concept implementation, because it is
unlikely that the OTR folks will integrate Namecoin into their
official code.  However, they indicated interest in a general
"verification framework" for Pidgin-OTR that would allow other
plug-ins to provide additional verification methods just like mine,
and I want to implement that.

The basic idea is like this:  Users have the official Pidgin-OTR
plug-in installed, and additionally a separate Namecoin plug-in.  When
the fingerprint verification process is started from the OTR plugin,
it looks through all installed plug-ins, determines which of those
provide fingerprint verification and then adds those as additional
options in the UI dialog.

Is something like this possible, and if so, how would I best implement
it?  In particular, how can the communication between the OTR plug-in
and verification plug-ins be done?  I presume that
purple_plugins_get_loaded is a start which could be used by OTR on
demand to get a list of all plug-ins installed (rather, active).  But
how could verification plug-ins signal to OTR that they indeed provide
verification features?  And how can OTR then tell those plug-ins to
build their UI, and vice-versa those plug-ins tell OTR to mark
fingerprints as verified?

My first idea would be to use signals:  If I understand them
correctly, one can basically connect any signal to any GObject, thus
would it be possible to achieve what I have in mind if each
verification plug-in connected a signal handler for, say,
"pidgin-otr-start-verification" to its PurplePlugin, and OTR fired
this signal on every plug-in loaded?  Then only those which are
actually verification plug-ins would handle the signal, and could take
appropriate action.  Via the user-data field for the signal handlers,
pointers to data-structures could be exchanged that can then be used
to communicate between OTR and the verifiers.

What do you think, is this a possible approach?  Are there other
(better) ways to handle my situation?  I've not much experience with
Glib and libpurple, so any help is very much appreciated!

Thanks!  Cheers,
Daniel

- -- 
http://www.domob.eu/
OpenPGP: 901C 5216 0537 1D2A F071  5A0E 4D94 6EED 04F7 CF52
- --
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSD6zhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ5MDFDNTIxNjA1MzcxRDJBRjA3MTVBMEU0
RDk0NkVFRDA0RjdDRjUyAAoJEE2Ubu0E989S350P+wS9B0EzG1ZCE+VJZNATfb2U
ViuGQOS3+ByqU0a8y0PZpy9V52K4XKNuJFGJbt1wuOHPK63eGVlD9FmTdJQc1myj
dgj7VTUxZ7ngbMrzC0We9CmcVBFckTBoEqFgy+OIEGyxegWqw3LLT6l6RDPfxpNv
Id8Dx3BputrTlLHwk35HEjPuPwidej0nkchMmolvTBKTVF+8BoXQJ5A90mpnsuhy
7dOa1itgxY/EKVwPGlmnhl2Z6Vz4c38rFgylPRSkMqRYwajlAJ8icKfmSXTXX/ya
jHbahqmnesukbEGB/4DbPbqZnH9yvjkFY+p3soNJ24U2WfQbJPTwx4kDQveu8iT6
46m3Wi/AcRMuLeylVVTb3cRn+d5a0By+6gCoNVmyTtMgHPxJwEXzvlIceMyU4DKh
RZFLIOXpO9wqdQSg1uppwiH9jDbec9cHaxdtt9IZK1kmFWdMwJpl19V27/GC1OSN
h3ejC8BuSlTk6pOc6b6Xe0aWbwQeGewWHzBdTLtgUZsu86RVRgz/qsoJb5vRmydt
xQqETxdIklUZoqzLJHakIzMKkCX+Xgwb9g/9AzX9Zpey9a4eqNNWvSpmJasx+Nu+
Xatm+Nq1xwzvgm6a3Bf5Zy4mI7x7SVhJYEuvIbMhplkPRmHYNZ3xKTjlBjr35hCA
ORsIdroGMmnX4vGQQedc
=Di6C
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4112 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://pidgin.im/pipermail/devel/attachments/20130817/0b4d884a/attachment.bin>


More information about the Devel mailing list