Publishes, retractions, purges, and deletions now raise the events:
- pubsub_publish
- pubsub_retract
- pubsub_purge
- pubsub_delete
In addition, custom events may be raised based on the node that
generated the notification. For example:
xmpp['xep_0060'].map_node_event('http://jabber.org/protocol/tune',
'user_tune')
will allow for using the events:
- user_tune_publish
- user_tune_retract
- user_tune_purge
- user_tune_delete
This was XEP-0237, but is now part of RFC 6121.
Roster backends should now expose two additional methods:
version(jid):
Return the version of the given JID's roster.
set_version(jid, version):
Update the version of the given JID's roster.
A new state field will be passed to the backend if an item
has been marked for removal. This is 'removed' which will
be set to True.
Each state element must have its own stanza class now. A stanza class
with an empty name field causes errors in ElementTree, even though
it works fine with cElementTree.
The payload is a dictionary of parsed cert data, as provided by
Python's getpeercert() socket method. It unfortunately does not
provide much detail beyond basic info.
This is inspired by the version from macdiesel and tomstrummer, but
their version was heavily linked with XEP-0096 and focused solely
on file transfer. This version is a more generic implementation.
Added new example for how to retrieve a Google token, following
the best case, non-browser, workflow. Other thirdparty auth
mechs (Facebook, MSN) follow a similar pattern of using an
access token.
This is mainly just useful for authenticating without using TLS.
If an access token is not provided, an attempt will be made to
retrieve one from Google.
Silently substituting the password field was nice, but for mechs
that can use either the password or an access token, it makes
things very difficult. This really only affects MSN clients since
Facebook clients should already be setting the api key.
This requires an extra credential for SASL authentication:
xmpp = ClientXMPP('user@chat.facebook.com', '...access_token...')
xmpp.credentials['api_key'] = '...api_key...'
The parsing and namespace cleaning isn't terribly expensive, but it does
add up. It was adding an extra 5sec when processing 100,000 basic
message stanzas.
Based on profiling, using around 35 stream handlers quarters the number
of basic message stanzas that can be processed in a second, in
comparison to only using the bare minimum of four handlers.
To help, we can drop handlers for stream features once the session
has started. So that we can re-enable these handlers when a stream
must restart, the 'stream_start' event has been added which fires
whenever a stream header is received.
The 'stream_start' event is a more generic replacement for the
existing start_stream_handler() method.
As part of adding this feature:
- fixed bug in update_caps() not assigning verstrings
- fixed xep_0004 typo
- can now use None as a roster key which will map to boundjid.bare
- fixed using JID objects in disco node handlers
- fixed failing test related to get_roster
Several of these bugs I've fixed before, so I either didn't push them
earlier, or I clobbered something when merging. *shrug*
New plugin configuration options:
use_cache - Enable caching disco info results. Defaults to True
wrap_results - Always return disco results in an Iq stanza. Defaults
to False
Node handler changes:
Handlers now take four arguments: jid, node, ifrom, data
Most older style handlers will still work, depending on if they
raise a TypeError for incorrect number of arguments. Handlers that
used *args may not work.
New get_info options:
cached - Passing cached=True to get_info() will attempt to load
results from the cache. If nothing is found, a query
will be sent as normal. If set to False, the cache
will be skipped, even if it contains results.
New method:
supports() - Given a JID/node pair and a feature, return True
if the feature is supported, False if not, and
None if there was a timeout. By default, the search
will use the cache.
Updated the XML-RPC value conversion to correctly apply namespaces, and
fixed an error uncovered by the tests in the XML -> Python conversion of
dateTime values.
This allows applications to filter out sensitive information, such
as passwords, so that it won't appear in the logs.
It does mean that the debug logs will not show the actual received
data, and there will be no indication of tampering, unless the
filter author explicitly logs and notes that a change was made.
A filter accepts and returns a stanza, but potentially modified.
To prevent sending/receiving a stanza, a filter may return None.
Incoming:
self.add_filter('in', in_filter)
Outgoing:
self.add_filter('out', out_filter)
Filters are applied in the order thay are added. However, you may
add an order parameter, which is the place in the list to insert the
filter:
self.add_filter('in', in_filter, order=0)
Only allowing handlers to return a DiscoInfo/DiscoItem stanza works
for the majority of cases, but does not allow for the addition of
an RSM stanza, or other extensions.
An Iq stanza returned by a handler must already be configured as
a reply.
May set self.disconnect_wait=True so that all disconnect
calls wait for the send queue to empty, unless explicitly
overridden with wait=False.
The session_end now fires before closing the socket so
that final stanzas may be sent, such as unavailable presences
for components.
The form plugin was being registered on first use for providers,
but not for clients receiving the form.
NOTE: Use of non-form payloads will have this issue - adhoc command
clients will need to have an expectation beforehand of what
the command payload will be to properly load stanza plugins.
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.
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
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
