| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
| |
A lot of the `rest` methods took - for example a Map - by value, where
they could instead take a reference. While this only prevents one clone
in the library, user-land code should no longer need to clone maps when
using the `rest` module.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Add the `send_file` method to:
- `model::Channel`
- `model::Group`
- `model::GuildChannel`
Add the `send_message` method to:
- `model::Channel`
Additionally, add more documentation for these with an example.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the Context having many methods removed, the doctests were
failing.
Update the doctests to use alternative methods to accomplish the same.
Example:
Before:
```rust
context.say("hi");
```
After:
```rust
message.channel_id.say("hi")
```
|
| | |
|
| |
|
|
|
|
| |
Most of the methods in the Context were for interacting with the related
ChannelId, but these methods have been re-implemented on ChannelId
itself, and is now the preferred (and now only) way to interact with it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Message deletions fall under a separate ratelimit apart from the route's
global ratelimit, and so the DELETE verb for the route is now separately
handled.
This is documented [here] as the following (at the time of this
writing):
> There is currently a single exception to the above rule regarding
> different HTTP methods sharing the same rate limit, and that is for
> the deletion of messages. Deleting messages falls under a separate,
> higher rate limit so that bots are able to more quickly delete content
> from channels (which is useful for moderation bots).
[here]: https://discordapp.com/developers/docs/topics/rate-limits#rate-limits
|
| |
|
|
|
|
|
| |
Instead of assuming every request is successful, check that the class of
the status is successful (2xx), and if not, return a
`ClientError::InvalidRequest`, which is a renamed
`ClientError::UnexpectedStatusCode`.
|
| | |
|
| |
|
|
|
|
|
|
| |
Allow voice connections be built standalone from the primary websocket
connection to the gateway. This has the side-effect of reduced
functionality (e.g. muting or deafening only update the internal handler
state), but allows voice connections to be handled independently from
the rest of the lib.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Improve the cache by keeping track of new maps, making other maps have
`Arc<RwLock>` values, optimizing already-existing methods, and take advantage
of new, more efficient retrievals (e.g. simply keying a value from a map rather
than iterating over vecs or maps and then itering over another vec).
Keep track of two new maps in the cache:
- **channels**: a map of all guild channels that exist, so that they can be
efficiently found, and so a message's guild can be efficiently found
- **users**: a map of all users that exist, so that it can be shared across
all members and presences
Other cache fields now have `Arc<RwLock>` values:
- `groups`
- `guilds`
- `private_channels`
`Cache::unavailable_guilds` is now a `HashSet<GuildId>` instead of a
`Vec<GuildId>`. This should slightly optimize removals/insertions for large
bots.
`ext::cache::ChannelRef` has been removed as it became equivilant in
functionality to `model::Channel`. Also, `model::Channel` now has all variant
data encased in `Arc<RwLock>`s. E.g., `Channel::Group(Group)` is now
`Channel::Group(Arc<RwLock<Group>>)`.
Some model struct fields are now wrapped in an `Arc<RwLock>`. These are:
- `Group::recipients`: `HashMap<UserId, User>` -> `HashMap<UserId, Arc<RwLock<User>>>`
- `Guild::channels`: `HashMap<ChannelId, GuildChannel>` -> `HashMap<ChannelId, Arc<RwLock<GuildChannel>>>`
- `Member::user`: `User` -> `Arc<RwLock<User>>`
- `PrivateChannel::recipient`: `User` -> `Arc<RwLock<User>>`
Some (cache-enabled) event handler signatures have changed to use
`Arc<RwLock>`s:
- `Client::on_call_delete`
- `Client::on_call_update`
- `Client::on_guild_delete`
- `Client::on_guild_update`
Many function signatures have changed:
- `Cache::get_call` now returns a `Option<Arc<RwLock<Call>>>` instead of a
`Option<&Call>`
- `Cache::get_channel` now returns a `Option<Channel>` instead of a
`Option<ChannelRef>`. This now also retrieves directly from the
`Guild::channels` instead of iterating over guilds' for a guild channel
- `Cache::get_guild` now returns a `Option<Arc<RwLock<Guild>>>` instead of a
`Option<&Guild>`
- `Cache::get_guild_channel` now returns a `Option<Arc<RwLock<GuildChannel>>>`
instead of a `Option<&GuildChannel>`
- `Cache::get_group` now returns a `Option<Arc<RwLock<Group>>>` instead of a
`Option<&Group>`
- `Cache::get_member` now returns a `Option<Member>` instead of a
`Option<&Member>`, due to guilds being behind a lock themselves
- `Cache::get_role` now returns a `Option<Role>` instead of a `Option<&Role>`
for the above reason
- `Cache::get_user` now returns a `Option<Arc<RwLock<User>>>` instead of a
`Option<&User>`
- `GuildId::find` now returns a `Option<Arc<RwLock<Guild>>>` instead of a
`Option<Guild>`
- `UserId::find` now returns a `Option<Arc<RwLock<User>>>` instead of a
`Option<User>`
- `Member::display_name` now returns a `Cow<String>` instead of a `&str`
A new cache method has been added, `Cache::get_private_channel`, to retrieve a
`PrivateChannel`.
The `Display` formatter for `Channel` has been optimized to not clone.
|
| |
|
|
|
| |
There used to be a method to do the equivilant but was lost in the move
to an OOP pattern, so this should be re-added back.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Instead of making the GLOBAL ratelimit arc-mutex a RateLimit, make it an
empty unit.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When attempting to use a named argument with a type of String, the
framework will try to parse the received argument - a String - into a
String. This can never fail, so Rust warns that the `Err` arm of the
`match` can never be reached.
Let's just ignore that and everything will be fine.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When autosharding, the `GET /gateway/bot` URL would be requested to
determine shard count. Then, `Client::start_connection` would be called,
passing the shard settings. This, in turn, would call
`rest::get_gateway`. This was essentially calling for the same URL
twice. Instead, have each of the different sharding methods request the
gateway URL themselves, and pass into `Client::start_connection`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of returning a generic `Channel` enum, make the following
functions return an explicit GuildChannel instead of a more "generic"
Channel enum:
- Guild::create_channel
- GuildId::create_channel
- PartialGuild::create_channel
- rest::create_channel
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Instead of binding to `_why`, bind to `_`, dropping the value.
This is pretty much just leftover from when the library was being
rapidly developed before being released.
|
| |
|
|
|
|
|
| |
When passing monitoring info from the shard handler to the dispatch
function, pass arguments by reference instead of by cloning and passing
by reference. Additionally, don't re-clone handler Arcs and temporary
Messages.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The context is now strictly in relation to the context of the current
channel related to the event, if any. See Context::say for a list of
events that the context can be used for.
|
| | |
|