| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `model` module has historically been one giant module re-exporting
all of the model types, which is somewhere around 100 types. This can be
a lot to look at for a new user and somewhat overwhelming, especially
with a large number of fine-grained imports from the module.
The module is now neatly split up into submodules, mostly like it has
been internally since the early versions of the library. The submodules
are:
- application
- channel
- error
- event
- gateway
- guild
- id
- invite
- misc
- permissions
- prelude
- user
- voice
- webhook
Each submodule contains types that are "owned" by the module. For
example, the `guild` submodule contains, but not limited to, Emoji,
AuditLogsEntry, Role, and Member. `channel` contains, but not limited
to, Attachment, Embed, Message, and Reaction.
Upgrade path:
Instead of glob importing the models via `use serenity::model::*;`,
instead glob import via the prelude:
```rust
use serenity::model::prelude::*;
```
Instead of importing from the root model module:
```rust
use serenity::model::{Guild, Message, OnlineStatus, Role, User};
```
instead import from the submodules like so:
```rust
use serenity::model::channel::Message;
use serenity::model::guild::{Guild, Role};
use serenity::model::user::{OnlineStatus, User};
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is a rewrite of the client module's internals and the
gateway.
The main benefit of this is that there is either 0 or 1 lock retrievals
per event received, and the ability to utilize the ShardManager both
internally and in userland code has been improved.
The primary rework is in the `serenity::client` module, which now
includes a few more structures, some changes to existing ones, and more
functionality (such as to the `ShardManager`).
The two notable additions to the client-gateway bridge are the
`ShardMessenger` and `ShardManagerMonitor`.
The `ShardMessenger` is a simple-to-use interface for users to use to
interact with shards. The user is given one of these in the
`serenity::client::Context` in dispatches to the
`serenity::client::EventHandler`. This can be used for updating the
presence of a shard, sending a guild chunk message, or sending a user's
defined WebSocket message.
The `ShardManagerMonitor` is a loop run in its own thread, potentially
the main thread, that is responsible for receiving messages over an mpsc
channel on what to do with shards via the `ShardManager`. For example,
it will receive a message to shutdown a single shard, restart a single
shard, or shutdown the entire thing.
Users, in most applications, will not interact with the
`ShardManagerMonitor`. Users using the `serenity::client::Client`
interact with only the `ShardMessenger`.
The `ShardManager` is now usable by the user and is available to them,
and contains public functions for shutdowns, initializations, restarts,
and complete shutdowns of shards. It contains utility functions like
determining whether the `ShardManager` is responsible for a shard of a
given ID and the IDs of shards currently active (having an associated
`ShardRunner`). It can be found on
`serenity::client::Client::shard_manager`.
Speaking of the `ShardRunner`, it no longer owns a clone of an Arc to
its assigned `serenity::gateway::Shard`. It now completely owns the
Shard. This means that in order to open the shard, a `ShardRunner` no
longer has to repeatedly retrieve a lock to it. This reduces the number
of lock retrievals per event dispatching cycle from 3 or 4 depending on
event type to 0 or 1 depending on whether it's a message create _and_ if
the framework is in use. To interact with the Shard, one must now go
through the previously mentioned `ShardMessenger`, which the
`ShardRunner` will check for messages from on a loop.
`serenity::client::Context` is now slightly different. Instead of the
`shard` field being `Arc<Mutex<Shard>>`, it is an instance of a
`ShardMessenger`. The interface is the same (minus losing some
Shard-specific methods like `latency`), and `Context`'s shortcuts still
exist (like `Context::online` or `Context::set_game`). It now
additionally includes a `Context::shard_id` field which is a u64
containing the ID of the shard that the event was dispatched from.
`serenity::client::Client` has one changed field name, one field that is
now public, and a new field. `Client::shard_runners` is now
`Client::shard_manager` of type `Arc<Mutex<ShardManager>>`. The
`Client::token` field is now public. This can, for example, be mutated
on token resets if you know what you're doing. `Client::ws_uri` is new
and contains the URI for shards to use when connecting to the gateway.
Otherwise, the Client's usage is unchanged.
`serenity::gateway::Shard` has a couple of minor changes and many more
public methods and fields. The `autoreconnect`, `check_heartbeat`,
`handle_event`, `heartbeat`, `identify`, `initialize`, `reset`,
`resume`, `reconnect`, and `update_presence` methods are now public. The
`token` structfield is now public. There are new getters for various
structfields, such as `heartbeat_instants` and `last_heartbeat_ack`.
The breaking change on the `Shard` is that `Shard::handle_event` now
takes an event by reference and, instead of returning
`Result<Option<Event>>`, it now returns `Result<Option<ShardAction>>`.
`serenity::gateway::ShardAction` is a light enum determining an action
that someone _should_/_must_ perform on the shard, e.g. reconnecting or
identifying. This is determined by `Shard::handle_event`.
In total, there aren't too many breaking changes that most of userland
use cases has to deal with -- at most, changing some usage of `Context`.
Retrieving information like a Shard's latency is currently not possible
anymore but work will be done to make this functionality available
again.
|
| |
|
|
|
|
|
|
| |
The client now returns a Result in preparation of a future commit.
Upgrade path:
Handle the case of an error via pattern matching, or unwrap the Result.
|
| |
|
|
|
| |
It was voted that the `on_` prefix is unnecessary, so these have been
dropped.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While selfbots have always been "roughly tolerated", lately they have
been tolerated to less of a degree.
The simple answer is to no longer support selfbots in any form. This is
done for a few of reasons: 1) in anticipation of selfbots no longer
being tolerated; 2) there are few reasons why one should make a selfbot
in Rust and not a scripting language; 3) there are alternatives
(i.e. discord-rs) that still support userbots. Selfbots are simply not
a goal of the maintainer of serenity.
Upgrade path:
Don't use selfbots with serenity. Use discord-rs instead.
The following has been removed:
Enums:
- `RelationshipType`
Structs:
- `FriendSourceFlags`
- `ReadState`
- `Relationship`
- `SearchResult`
- `SuggestionReason`
- `Tutorial`
- `UserConnection`
- `UserGuildSettings`
- `UserSettings`
Removed the following fields:
- `CurrentUser::mobile`
- Ready::{
analytics_token,
experiments,
friend_suggestion_count,
notes,
read_state,
relationships,
tutorial,
user_guild_settings,
user_settings,
}
Removed the following methods:
- `Client::login_user`
Deprecated `Client::login_bot` in favour of `Client::login`.
Removed `client::LoginType`.
The following no longer take a `login_type` parameter:
- `Context::new`
- `Shard::new`
`Shard::sync_guilds` has been removed.
The `client::Error::{InvalidOperationAsBot, InvalidOperationAsUser}`
variants have been removed.
The following event handlers on `Client` have been removed:
- `on_friend_suggestion_create`
- `on_friend_suggestion_delete`
- `on_relationship_add`
- `on_relationship_remove`
- `on_user_guild_settings_update`
- `on_note_update`
- `on_user_settings_update`
The following `client::rest` functions have been removed:
- `ack_message`
- `edit_note`
- `get_user_connections`
- `search_channel_messages`
- `search_guild_messages`
The following `client::rest::ratelimiting::Route` variants have been
removed:
- `ChannelsIdMessagesSearch`
- `GuildsIdMessagesSearch`
- `UsersMeConnections`
The following fields on `ext::cache::Cache` have been removed:
- `guild_settings`
- `relationships`
- `settings`
while the following methods have also been removed:
- `update_with_relationship_add`
- `update_with_relationship_remove`
- `update_with_user_guild_settings_update`
- `update_with_user_note_update`
- `update_with_user_settings_update`
The following methods have been removed across models:
- `ChannelId::{ack, search}`
- `Channel::{ack, search}`
- `Group::{ack, search}`
- `GuildChannel::{ack, search}`
- `GuildId::{search, search_channels}`
- `Guild::{search, search_channels}`
- `Message::ack`
- `PartialGuild::{search, search_channels}`
- `PrivateChannel::{ack, search}`
- `UserId::{delete_note, edit_note}`
- `User::{delete_note, edit_note}`
The following events in `model::events` have been removed:
- `FriendSuggestionCreateEvent`
- `FriendSuggestionDeleteEvent`
- `MessageAckEvent`
- `RelationshipAddEvent`
- `RelationshipRemoveEvent`
- `UserGuildSettingsUpdateEvent`
- `UserNoteUpdateEvent`
- `UserSettingsUpdateEvent`
Consequently, the following variants on `model::event::Event` have been
removed:
- `FriendSuggestionCreate`
- `FriendSuggestionDelete`
- `MessageAdd`
- `RelationshipAdd`
- `RelationshipRemove`
- `UserGuildSettingUpdate`
- `UserNoteUpdate`
- `UserSettingsUpdate`
The `utils::builder::Search` search builder has been removed.
|
| |
|
|
|
|
| |
Due to many of the channel methods being removed from the Context (due
to basically duplicating methods and code from `ChannelId`), update
all of the examples to use methods on `ChannelId` instead.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Instead of pointing to the current minor version, the examples'
`Cargo.toml`s should be a relative path to the current cloned repo. This
improves the examples by:
1. always being up-to-date if major or minor version updates occur;
2. being more up-to-standard with the examples' readme;
3. making debugging the library locally easier (not having to constantly
modify the version to a path).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
The examples include a README located in `examples/README.md`, which
contains instructions for running these examples.
They act as a simple form of tutorial to the library, without getting
into too many details.
|
| |
|