Mercurial > pidgin.yaz
view doc/imgstore-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 <evan.s@dreskin.net>
author | Stu Tomlinson <stu@nosnilmot.com> |
---|---|
date | Sun, 13 Apr 2008 06:37:47 +0000 |
parents | e0613cf8c493 |
children |
line wrap: on
line source
/** @page imgstore-signals Image Store Signals @signals @signal image-deleting @endsignals @see imgstore.h <hr> @signaldef image-deleting @signalproto char *(*image_deleting)(const PurpleStoredImage *img); @endsignalproto @signaldesc Emitted when a #PurpleStoredImage is about to be destroyed. This allows for what amounts to weak references. Code can hold onto a pointer to the PurpleStoredImage without actually "holding" a reference. They can then use a signal handler to let them know when their img is about to be destroyed. @param img The image about to be destroyed. @note It's not possible to purple_imgstore_ref() img to save it. @endsignaldef */ // vim: syntax=c.doxygen tw=75 et