view doc/certificate-signals.dox @ 22640:23fe481afccf

The next version of RFC 3920, the draft of which can be found at http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-04.html, and subsequent email clarifications with Peter Saint-Andre and Alexey Melnikov indicate that we should be trying the next mechanism in line after one mechanism fails. We should also be ensuring that the mech list is sorted in order of descending security, which we don't do yet; however, servers are supposed to send us a sorted list, as well, so this isn't a major issue. committer: Evan Schoenberg <[e-mail]>

/** @page certificate-signals Certificate Signals

 @signals
  @signal certificate-stored
  @signal certificate-deleted
 @endsignals

 @see certificate.h

 <hr>

 @signaldef certificate-stored
  @signalproto
void (*certificate_stored)(PurpleCertificatePool *pool, const gchar *id, gpointer data);
  @endsignalproto
  @signaldesc
   Emitted when a pool stores a certificate. Connect to the pool instance.
  @param pool    Pool the certificate has been stored into
  @param id      Key the certificate was stored under
 @endsignaldef

 @signaldef certificate-deleted
  @signalproto
void (*certificate_deleted)(PurpleCertificatePool *pool, const gchar *id, gpointer data);
  @endsignalproto
  @signaldesc
   Emitted when a pool deletes a certificate. Connect to the pool instance.
  @param pool    Pool the certificate was deleted from
  @param id      Key that was deleted
 @endsignaldef

 */
// vim: syntax=c.doxygen tw=75 et