Mercurial > pidgin.yaz
view doc/log-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 | 0d8061bbfc1d |
children |
line wrap: on
line source
/** @page log-signals Log Signals @signals @signal log-timestamp @endsignals @see log.h <hr> @signaldef log-timestamp @signalproto char *(*log_timestamp)(PurpleLog *log, time_t when, gboolean show_date); @endsignalproto @signaldesc Emitted to allow plugins to customize the timestamp on a message being logged. @param log The log the message belongs to. @param when The time to be converted to a string. @param show_date Whether the date should be displayed. @return A textual representation of the time, or @c NULL to use a default format. @note Plugins must be careful of logs with a type of PURPLE_LOG_SYSTEM. @endsignaldef */ // vim: syntax=c.doxygen tw=75 et