Using `reqwest` with default-features enabled will enable the
`default-tls`, which in turn will enable the `native-tls` feautre which
will result in an attempt to compile against OpenSSL [0]. If one wants
to use `mastodon-async` without depending on OpenSSL, the default
features for `reqwest` must be disabled.
The default features for `mastodon-async` will enable
`reqwest/default-tls`, so the default behaviour won't change, but now it
is possible to declare the dependency on `mastodon-async` with default
features disabled and the `rustls-tls` feature enabled, allowing to
compile without a dependency on OpenSSL.
[0]: e02df1f448/Cargo.toml (L30)
This patch makes the "version", "license", "authors" and "edition"
fields in the manifest workspace-wide.
This way we ensure that mastodon-async-entities stays in sync with
mastodon-async.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
This patch move the entities module to a helper-crate.
With this, we give the user the opportunity to use only the entities
types in their codebase, if need be.
One scenario where this is required came up in
https://github.com/dscottboggs/mastodon-async/issues/38
TL;DR is: A user needed to be able to pass types like `Status` from a
backend part of an application to a frontend which was compiled to WASM.
Because mastodon_async depends on tokio, which does not compile to WASM
(at least not with the features required by mastodon_async).
One option would have been to provide types in the application code
which can be constructed from mastodon_asyncs entity types. This would
lead to _a lot_ of code duplication (over several projects still,... but
that's rather undesireable anyways).
The solution mastodon_async offers with this patch is a helper-crate
which only contains the entity types: mastodon_async_entities.
mastodon_async publicly exports the whole mastodon_async_entities crate,
so users do not have to depend on the latter directly.
In addition to the `entities` module from mastodon_async, also the
`Visibility` type had to be moved.
`mastodon_async_entities` also got an own `Error` type, which
`mastodon_async::Error` can of course wrap.
Signed-off-by: Matthias Beyer <mail@beyermatthias.de>
Suggested-by: D. Scott Boggs <scott@tams.tech>
There were too many false positive responses from libmagic to have this
just happen in the background. In a future release I may add a specific
error which is returned when the given file has no extension, and
downstream application developers can use that as an indicator that they
should ask the user if they want to detect the filetype, making use of
libmagic directly in the downstream application as appropriate.
This fixes a bug where a chunked response would be partially read and then hang forever waiting for another chunk, and adds additional debug logging to the request process.
- Use reqwest's async client
- Convert items_iter() to a futures::Stream
- make Mastodon client an Arc smart pointer, removing the need for OwnedPage.
- remove MastodonClient and HttpSender traits; these can be re-added once async trait fns are stabilized
- make EventStream a futures::Stream