Mercurial > pidgin.yaz
view doc/log-signals.dox @ 25086:6a0304f317cf
I was hoping this wouldn't be necessary, but it seems that the possibility
has increased now that we update the display name in the AB.
If two SOAP requests fail because of outdated tokens for the same server,
it's possible that the second one could fail miserably. That's because both
times, the update request would be made with the original cipher secret.
However, the response for the first request would overwrite this secret,
and the second response would attempt decryption with this new secret
instead of the original.
Now, we queue up the callbacks if a token-update is already in progress.
This results in a single update if there happens to be multiple failures at
a time, and it stops this incorrect decryption problem.
Fixes #8415.
author | Elliott Sales de Andrade <qulogic@pidgin.im> |
---|---|
date | Sun, 15 Feb 2009 02:11:58 +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