Age | Commit message (Collapse) | Author |
|
Fixes issue #118
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Calling reconnect() simultaneously from multiple threads (like when
using XEP-0199 keepalive) could break because the connection state
can transition and break the state expectations in one of the
reconnect() calls.
|
|
This may need to be reverted if CTRL-C handling breaks, but everything
works fine so far in testing.
Resolves issue #95.
|
|
|
|
|
|
|
|
|
|
|
|
Conflicts:
examples/ping.py
sleekxmpp/basexmpp.py
sleekxmpp/clientxmpp.py
sleekxmpp/features/feature_bind/bind.py
sleekxmpp/features/feature_mechanisms/mechanisms.py
sleekxmpp/plugins/gmail_notify.py
sleekxmpp/plugins/jobs.py
sleekxmpp/plugins/xep_0009/remote.py
sleekxmpp/plugins/xep_0009/rpc.py
sleekxmpp/plugins/xep_0012.py
sleekxmpp/plugins/xep_0045.py
sleekxmpp/plugins/xep_0050/adhoc.py
sleekxmpp/plugins/xep_0078/legacyauth.py
sleekxmpp/plugins/xep_0085/chat_states.py
sleekxmpp/plugins/xep_0199/ping.py
sleekxmpp/plugins/xep_0224/attention.py
sleekxmpp/xmlstream/handler/waiter.py
sleekxmpp/xmlstream/matcher/xmlmask.py
sleekxmpp/xmlstream/xmlstream.py
Conflicts:
examples/ping.py
sleekxmpp/basexmpp.py
sleekxmpp/clientxmpp.py
sleekxmpp/features/feature_bind/bind.py
sleekxmpp/features/feature_mechanisms/mechanisms.py
sleekxmpp/plugins/gmail_notify.py
sleekxmpp/plugins/jobs.py
sleekxmpp/plugins/xep_0009/remote.py
sleekxmpp/plugins/xep_0009/rpc.py
sleekxmpp/plugins/xep_0012.py
sleekxmpp/plugins/xep_0045.py
sleekxmpp/plugins/xep_0050/adhoc.py
sleekxmpp/plugins/xep_0078/legacyauth.py
sleekxmpp/plugins/xep_0085/chat_states.py
sleekxmpp/plugins/xep_0199/ping.py
sleekxmpp/plugins/xep_0224/attention.py
sleekxmpp/xmlstream/handler/waiter.py
sleekxmpp/xmlstream/matcher/xmlmask.py
sleekxmpp/xmlstream/xmlstream.py
|
|
|
|
|
|
~ 15% of CPU on moderate load.
|
|
|
|
computing logging data that may never be used. This is a HUGE performance improvement; in some of my test runs, unnecessary string creation was accounting for > 60% of all CPU time.
Note that using % in a string will _always_ perform the sting substitutions, because the strings are constructed before the function is called. So log.debug('%s' % expensiveoperation()) will take about the same CPU time whether or not the logging level is DEBUG or INFO. if you use , no substitutions are performed unless the string is actually logged
|
|
computing logging data that may never be used. This is a HUGE performance improvement; in some of my test runs, unnecessary string creation was accounting for > 60% of all CPU time.
Note that using % in a string will _always_ perform the sting substitutions, because the strings are constructed before the function is called. So log.debug('%s' % expensiveoperation()) will take about the same CPU time whether or not the logging level is DEBUG or INFO. if you use , no substitutions are performed unless the string is actually logged
|
|
|
|
The roster portion of the example is too outdated.
|
|
|
|
Once again only fires when a resource's presence show value changes.
|
|
|
|
|
|
|
|
auto_reconnect=False.
|
|
|
|
Fixes issue #113
|
|
|
|
It messes up the auto_reconnect value and causes the XML processing
loop to spin wildly with errors on a stream disconnect.
|
|
|
|
The transition from disconnected to connected states must be done in a
loop in case the transition fails, not just once and hope it worked.
|
|
Original author: louiz
|
|
The change to using the new roster broke the original auto_* values
and used per-roster versions. The original auto_* values will now set
the behaviour globally. Use the per-roster values to override for a
specific JID.
|
|
The mechanism name was being correctly de-plussed, but then we used the
original, -PLUS, name to extract the hash, finding SHA-1-PLUS and therefore
finding no match.
Test-Information:
Tested with Sleek against an Isode M-Link with SCRAM-SHA-1-PLUS available.
Author: dwd
|
|
|
|
Should fix issue #107
|
|
|
|
|
|
Both are supported when reading, but <base64 /> will be used for output.
|
|
|
|
Fixes issue #105
|