Age | Commit message (Collapse) | Author |
|
NOTE: XEP-0313 is still very experimental, and there will likely be
API changes in the future.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
There are still a few remaining items in the RFCs to add support for,
but the current plugin support matches the advanced client profile.
|
|
Registering this plugin will load the plugins required for advanced
client compliance status.
|
|
|
|
|
|
|
|
|
|
|
|
It does not auto-retrieve and store avatars yet, but everything is there
to do so.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Honestly, this is mainly just a demo/proof of concept that we
can handle dependencies and ordering issues with stream features.
DON'T use XEP-0078 if you are able to use the normal SASL method,
which should be the case unless you are dealing with a very old
XMPP server implementation.
|
|
|
|
If dateutil is present, we'll use that. If not, we'll use
some regexes from the fixed_datetime module.
|
|
Thus, using the XEP-0082 and XEP-0202 introduces a dependency
on the dateutil package (installable using pip install python-dateutil).
Maybe we'll be able to rework how these plugins work to avoid
needing dateutil, but for now this will have to do.
|
|
|
|
|
|
|
|
* check_stanza does not require stanza_class parameter. Introspection!
* check_message, check_iq, and check_presence removed -- use check
instead.
* stream_send_stanza, stream_send_message, stream_send_iq, and
stream_send_presence removed -- use send instead.
* Use recv instead of recv_message, recv_presence, etc.
* check_jid instead of check_JID
* stream_start may accept multi=True to return a new SleekTest instance
for testing multiple streams at once.
|
|
Contributed by Cesar Alcalde.
|
|
Contributed by Cesar Alcalde.
|
|
|
|
references to nonexistant license.txt to LICENSE.
|
|
XEP-0033 can be useful for interacting with XMPP<->Email gateways.
|
|
Chat states may be set using:
msg['chat_state'].active()
msg['chat_state'].composing()
msg['chat_state'].gone()
msg['chat_state'].inactive()
msg['chat_state'].paused()
Checking a chat state can be done with either:
msg['chat_state'].getState()
msg['chat_state'].name
When a message with a chat state is receieved, the following events
may occur:
chatstate_active
chatstate_composing
chatstate_gone
chatstate_inactive
chatstate_paused
where the event data is the message stanza. Note that currently these
events are also triggered for messages sent by SleekXMPP, not just those
received.
|