Age | Commit message (Collapse) | Author |
|
Resolved by always normalizing JIDs to bare form, regardless of if they
are JID objects or strings.
Also simplified related code to prefer use of JID objects instead of
strings so they don't need to be parsed multiple times.
|
|
|
|
|
|
|
|
|
|
|
|
Remaining items are suitable default actions for language supporting
interfaces.
|
|
|
|
Certificate host names are now matched (using DNS, SRV, XMPPAddr, and
Common Name), along with expiration check.
Scheduled event to reset the stream once the server's cert expires.
Handle invalid cert trust chains gracefully now.
|
|
leaves it blank.
|
|
The API registry generalizes the node handler system from the xep_0030
plugin so that other plugins can use it.
|
|
Plugins that are referenced as dependencies, but have not been
registered now will be imported. Newer plugins should register
themselves automatically, but older style plugins will be
explicitly registered after import.
|
|
The new system is backward compatible and will load older style plugins.
The new plugin framework allows plugins to track their dependencies, and
will auto-enable plugins as needed.
Dependencies are tracked via a class-level set named `dependencies` in
each plugin.
Plugin names are no longer tightly coupled with the plugin class name,
Pso EP8 style class names may be used.
Disabling plugins is now allowed, but ensuring proper cleanup is left to
the plugin implementation.
The use of a `post_init()` method is no longer needed for new style
plugins, but plugins following the old style will still require a
`post_init()` method.
|
|
The post_init() system can only reliably handle a single layer
of dependencies between plugins, but PEP plugins with XEP-0115
exceed that limit and plugins can be post_init'ed out of order. To
resolve this, we will special case XEP-0115 to be post_init'ed
first until the new plugin system with dependency tracking is
stable.
|
|
|
|
This would happen when receiving presence without a 'to' field, which
happens when receiving presence from other resources for the same account.
|
|
|
|
|
|
The exceptions are handled, so we don't need to clutter the output logs.
|
|
|
|
|
|
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
|
|
Once again only fires when a resource's presence show value changes.
|
|
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.
|
|
IqError and IqTimeout now extend XMPPError, so if you don't care
about the difference, you can use:
try:
self.do_something_with_iqs()
except XMPPError:
# Error? Timeout? I don't care!
pass
If you do need to distinguish between timeouts and error replies,
you can still continue to use:
try:
self.do_somethin_with_iqs()
except IqError as err:
pass
except IqTimeout:
pass
If you don't catch any Iq errors and you're processing a stanza
then an error response will be sent, just like normal if you raise
XMPPError or any other exception, except that the error messages
will be generic to prevent leaking too much information.
|
|
|
|
Conflicts:
setup.py
sleekxmpp/clientxmpp.py
|
|
|
|
Sleek loads a few plugins by default, which made it difficult to
configure or even disable them.
Now, if a plugin is registered without any configuration, then
sleek will try finding a configuration in self.plugin_config.
|
|
|
|
example to ClientXMPP.
|
|
Conflicts:
setup.py
|
|
|
|
|
|
Last sent stanzas are saved regardless of if the roster is used
directly or self.send_presence
|
|
|
|
Caused by same issue of a JID being in the roster, but with an
incomplete entry.
|
|
Conflicts:
sleekxmpp/basexmpp.py
|
|
|
|
If the roster contained a JID, but not any resource presence data, then
an error would occur when accessing self.roster[jid]['presence'].
|
|
|
|
Conflicts:
sleekxmpp/xmlstream/stanzabase.py
|
|
|
|
Conflicts:
sleekxmpp/clientxmpp.py
|
|
This should prevent some reference cycles that will cause garbage
collection issues.
|
|
Conflicts:
sleekxmpp/basexmpp.py
|