| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
When clicking on an invite link without having a Discord account it's
possible to create an unclaimed account for joining the conversation
quickly. Add register() method to Client that performs and invite based
registration of an unclaimed account.
|
| |
|
|
|
| |
Check if the WebSocket connection was supposed to terminate and
reconnect to the gateway if this is not the case.
|
| |
|
|
|
|
|
|
|
|
| |
Guard the execution of dispatch with a recursive thread lock. This is
needed to make a thread safe way to send events to Client objects. Note
that the only thread safe method is dispatch, everything else is unsafe
to call from another thread, as the thead handling the Client object
could be modifying arbitrary structures at any time. In addition this
only keeps nasal demons away, and does not solve any of the difficult
syncronization issues that might be present.
|
| |
|
|
|
|
|
|
|
|
| |
Move the socket message handling and Discord connection state tracking
out of the Client class. The WebSocket class handles the ws4py based
WebSocket to Discord, maintains the keepalive and dispatches
socket_<events> based on activity. The ConnectionSTate class maintains
the state associated with the WebSocket connection with Discord. In a
reconnect and switch gateway scenario this state can be kept for a
faster and less disruptive recovery.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add event system based on a public dispatch method in Client. The new
event system bases itself on two types of events, internal event
handlers and user defined event handlers. Internal event handlers begin
with 'handle_', and user defined events begin with 'on_'. Events are
dispatched with dispatch(event_name, *args). The Client class should be
subclassed and the on_<event> handlers defined in it for responding to
events. The handle_<event> handlers can the overridden to override the
behaviour of the Client class, though this is not recommended.
The subclassing method allows separation of the instance of the client
and the code that handles it. (i.e. you don't need the instance of the
client object to define event handlers for it). Though, the old method
of using the event decorator from the instance will still be supported.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This means that it calls on_member_update just like the
GUILD_MEMBER_UPDATE event in an effort to keep some backwards compat.
|
| |
|
|
|
| |
Basically a lot of the request functions now return a booleean
indicating if the request was successful or not.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
_keep_alive_handler would set up another keep alive after the first one
by creating a new threading.Timer object, but Client would only keep
track of the first timer object. Thus casing the keep alive to continue
running after Client.logout calls cancel() on it's timer object, as it
no longer references the actual timer object waiting for the keep alive.
Fix by replacing _keep_alive_handler with a threading.Thread subclass
that sends keep_alives of the given interval and exits when its stop
event is set.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
owner will be the actual Member who owns the server.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This allows you to set or retrieve specific bits through a
higher level API to facilitate editing in the future.
|
| | |
|
| |
|
| |
When cycling through the attributes of the data json 'author' within 'message' which was previously a user object is overwritten with a dictionary. This causes an AttributeError to be thrown ( and silently swallowed... thanks except: pass) whenever any of its attributes are referenced in the form message.author.x. User data should change in this step and the user object should not be modified for any reason so its safe to skip updating it.
|
| | |
|