serenity - Unnamed repository; edit this file 'description' to name the repository.

	Commit message (Collapse)	Author	Age	Files	Lines
*	Merge branch 'futures' into v0.6.x	Zeyla Hellyer	2018-05-28	1	-19/+108
\|\
\| *	Add 'send_files' http support	Zeyla Hellyer	2018-03-26	1	-0/+10
\| \|
\| *	Rewrite the library to use Futures	Zeyla Hellyer	2018-02-04	1	-15/+96
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	Rewrites the library to use Futures. This rewrites all of the gateway, client, cache, most model methods, HTTP, and in a later commit the framework and voice. HTTP has been mostly rewritten to be ergonomic so that it can be used by the user, and has been upgraded to hyper v0.11. The gateway now uses `tokio-tungstenite` v0.4. The client isn't yet in a working state. The models now have a `client` optionally attached to them to make use of `http` and `cache`-utilizing methods. The client isn't needed, in the case that someone is using the library just to deserialize models. The cache is now built around `Rc`s and `RefCell`s, instead of `Arc`s and `RwLock`s. Refer to example 01 for a working example. Much of the library still doesn't work.
* \|	Refactor imports/exports to use nested groups and better formatting	acdenisSK	2018-03-29	1	-2/+8
\|/
*	Give hyper Response in HTTP errors	Zeyla Hellyer	2018-01-01	1	-9/+7
\| \| \| \| \| \| \| \|	Remove the `Error::UnknownStatus` variant, and change `Error::InvalidRequest(StatusCode)` to `Error::UnsuccessfulRequest(hyper::Response)`. This is done to give the user more information on why a request was unsuccessful, as before the user did not have access to the response body or headers.
*	rustfmt	acdenisSK	2017-07-27	1	-3/+1
\|
*	Restructure modules	Zeyla Hellyer	2017-05-22	1	-0/+35
	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.