| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fixes links to the repo from `https://github.com/zeyla/serenity` to
`https://github.com/serenity-rs/serenity`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Fixes #180, however this partially breaks `single_zc` and `multiple_quoted`, but since they're minor it's better to fix them later for now.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
Update the following dependencies:
- `base64` from `~0.6` to `~0.7`
- rust-websocket fork from `0.0.1` to `0.0.2`
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
| |
A threadpool will help with giving event dispatches a threaded behaviour
while still allowing the library the ability to perform other actions,
such as receiving new events and heartbeating over the websocket client.
|
| | |
|
| | |
|
| |
|
|
| |
The shard manager will queue up shards for booting.
|
| |
|
|
| |
This resolved compilation on stable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bitflags changed its macro codegen from creating constants to associated
constants on structs.
Upgrade path:
Update code from:
```rust
use serenity::model::permissions::{ADD_REACTIONS, MANAGE_MESSAGES};
foo(vec![ADD_REACTIONS, MANAGE_MESSAGES]);
```
to:
```rust
use serenity::model::Permissions;
foo(vec![Permissions::ADD_REACTIONS, Permissions::MANAGE_MESSAGES]);
```
|
| | |
|
| |
|
|
|
| |
This fixes compilation errors and warnings when compiling a mixture of
non-default feature targets.
|
| | |
|
| |
|
|
| |
Fixes #142
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The framework is now moved in its entirity to the `framework` module,
with the `Framework` trait currently on its own and the builtin
implementation provided.
The builtin implementation has been renamed to "Standard".
Upgrade path:
Rename the `BuiltinFramework` import to `StandardFramework`. Instead of
importing builtin framework items from `serenity::framework`, import
them from `serenity::framework::standard`.
This is the beginning to #60. The root `framework` module (non-standard
implementation) will be built more by the time it's closed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Removed action support from the builtin one as well, due to it adding some uneccassery complexity and it being only asked upon by one user
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Upgrade `rust-websocket` to v0.20, maintaining use of its sync client.
This indirectly switches from `rust-openssl` v0.7 - which required
openssl-1.0 on all platforms - to `native-tls`, which allows for use of
schannel on Windows, Secure Transport on OSX, and openssl-1.1 on other
platforms.
Additionally, since hyper is no longer even a dependency of
rust-websocket, we can safely and easily upgrade to `hyper` v0.10 and
`multipart` v0.12.
This commit is fairly experimental as it has not been tested on a
long-running bot.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Chrono is easier to use than timestamped strings, so they should be
automatically deserialized and available for the user, instead of having
the user deserialize the strings themselves.
These fields have been changed to use a type of `DateTime<FixedOffset>`:
- `ChannelPinsUpdateEvent.last_pin_timestamp`
- `Group.last_pin_timestamp`
- `Guild.joined_at`
- `GuildChannel.last_pin_timestamp`
- `Invite.created_at`
- `Member.joined_at`
- `Message.edited_timestamp
- `Message.timestamp`
- `MessageUpdateEvent.edited_timestamp`
- `MessageUpdateEvent.timestamp`
- `PrivateChannel.last_pin_timestamp`
`Member.joined_at` is now also an `Option`. Previously, if a Guild
Member Update was received for a member not in the cache, a new Member
would be instantiated with a default String value. This is incorrect
behaviour, and has now been replaced with being set to `None` in that
case.
Id methods' `created_at()` method now return a `chrono::NaiveDateTime`
instead of a `time::Timespec`, and `User::created_at` has been updated
to reflect that.
Additionally, drop `time` as a direct dependency and use chrono for
internals.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Modules are now separated into a fashion where the library can be used
for most use cases, without needing to compile the rest.
The core of serenity, with no features enabled, contains only the
struct (model) definitions, constants, and prelude. Models do not have
most functions compiled in, as that is separated into the `model`
feature.
The `client` module has been split into 3 modules: `client`, `gateway`,
and `http`.
`http` contains functions to interact with the REST API. `gateway`
contains the Shard to interact with the gateway, requiring `http` for
retrieving the gateway URL. `client` requires both of the other features
and acts as an abstracted interface over both the gateway and REST APIs,
handling the event loop.
The `builder` module has been separated from `utils`, and can now be
optionally compiled in. It and the `http` feature are required by the
`model` feature due to a large number of methods requiring access to
them.
`utils` now contains a number of utilities, such as the Colour struct, the
`MessageBuilder`, and mention parsing functions.
Each of the original `ext` modules are still featured, with `cache` not
requiring any feature to be enabled, `framework` requiring the `client`,
`model`, and `utils`, and `voice` requiring `gateway`.
In total the features and their requirements are:
- `builder`: none
- `cache`: none
- `client`: `gateway`, `http`
- `framework`: `client`, `model`, `utils`
- `gateway`: `http`
- `http`: none
- `model`: `builder`, `http`
- `utils`: none
- `voice`: `gateway`
The default features are `builder`, `cache`, `client`, `framework`,
`gateway`, `model`, `http`, and `utils`.
To help with forwards compatibility, modules have been re-exported from
their original locations.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Update the dependencies `base64`, `bitflags`, `byteorder`, `serde`,
`serde_derive`, and `serde_json`.
These dependencies have been updated, with byteorder and serde** hitting
v1.0.0, so they should be updated for the v0.2.0 serenity release.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current build system is rudimentary, incomplete, and rigid, offering
little in the way of customizing decoding options.
To solve this, switch to using serde-derive with custom Deserialization
implementations. This allows very simple deserialization when special
logic does not need to be applied, yet allows us to implement our own
deserialization logic when required.
The problem with the build system was that it built enums and structs
from YAML files. This is not so good, because it requires creating a
custom build system (which was rudimentary), creating "special struct
configs" when logic needed to be ever so slightly extended (rigid), and
if special logic needed to be applied, a custom deserialization method
would have been needed to be made anyway (incomplete).
To solve this, switch to serde-derive and implementing Deserialize
ourselves where required. This reduces YAML definitions that might
look like:
```yaml
---
name: Group
description: >
A group channel, potentially including other users, separate from a [`Guild`].
[`Guild`]: struct.Guild.html
fields:
- name: channel_id
description: The Id of the group channel.
from: id
type: ChannelId
- name: icon
description: The optional icon of the group channel.
optional: true
type: string
- name: last_message_id
description: The Id of the last message sent.
optional: true
type: MessageId
- name: last_pin_timestamp
description: Timestamp of the latest pinned message.
optional: true
type: string
- name: name
description: The name of the group channel.
optional: true
type: string
- name: owner_id
description: The Id of the group channel creator.
type: UserId
- name: recipients
description: Group channel's members.
custom: decode_users
t: UserId, Arc<RwLock<User>>
type: hashmap
```
to:
```rs
/// A group channel - potentially including other [`User`]s - separate from a
/// [`Guild`].
///
/// [`Guild`]: struct.Guild.html
/// [`User`]: struct.User.html
pub struct Group {
/// The Id of the group channel.
#[serde(rename="id")]
pub channel_id: ChannelId,
/// The optional icon of the group channel.
pub icon: Option<String>,
/// The Id of the last message sent.
pub last_message_id: Option<MessageId>,
/// Timestamp of the latest pinned message.
pub last_pin_timestamp: Option<String>,
/// The name of the group channel.
pub name: Option<String>,
/// The Id of the group owner.
pub owner_id: UserId,
/// A map of the group's recipients.
#[serde(deserialize_with="deserialize_users")]
pub recipients: HashMap<UserId, Arc<RwLock<User>>>,
}
```
This is much simpler and does not have as much boilerplate.
There should not be any backwards incompatible changes other than the
old, public - yet undocumented (and hidden from documentation) - decode
methods being removed. Due to the nature of this commit, field names may
be incorrect, and will need to be corrected as deserialization errors
are found.
|
| |
|
|
|
|
| |
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.
|