This proved very difficult due to the different ownership behavior
between each builder, i.e. warp is a consuming builder, actix isn't.
With the use of the Rc/Cell/RefCell, I worry that this is now more
complex than it was, and for all I know, I've introduced a memory leak
somewhere. :)
Since the reqwest builder is also consuming, it should be able to
follow the same "adapter" pattern as warp. Unfortunately, the reqwest
builder doesn't implement the Default trait, so I can't use take() and
I've yet to come up with another solution.
Since 2/3 of the builders are consumers, it's possible we might
simplify the code by having the new Builder trait reflect that,
i.e. using self instead of &self in the fn params. We'll investigate
that next.
For now, I'm just happy to have 2 builders sharing some formerly
redundant behavior.
Signed-off-by: Jim Crossley <jim@crossleys.org>
Both warp and reqwest use the HeaderMap from the http crate. Actix has
its own. Fortunately, both contain (HeaderName, HeaderValue) tuples.
Further, actix uses a conflicting version of the bytes crate, so I
store a Vec<u8> instead of a Bytes member in the Deserializer
struct. Not sure if that's a problem, but the tests pass. :)
We use an associated type in the Headers trait to facilitate static
dispatch for warp/reqwest since their concrete iterator is public, but
the actix Iter struct is private, so we use a Box for its impl.
We're using AsHeaderName for the get() param to avoid having to call
as_str() on any header constants, but of course actix uses its own
AsName trait, which isn't public, so we must call as_str() for the
passed header name in its impl.
Signed-off-by: Jim Crossley <jim@crossleys.org>
* Refactor redundant header logic to a shared lib
* Remove some unused code
* Share macro between actix and warp, eliminating actix header mod
Fixes#145
Signed-off-by: Jim Crossley <jim@crossleys.org>
* Fix null extensions and fields in json
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* fmt
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Renamed features
Moved all bindings under a binding crate
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Cargo fmt
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Now this should build
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Use the new cache plugin
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Fix
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Fix the build
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Fixed doc links
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
* Change link
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Now that we've refactored the protocol bindings from crates to
feature-guarded modules (PR #131), we can remove the workspaces for
those crates.
Signed-off-by: Jim Crossley <jim@crossleys.org>
Fixes#130
I'm not entirely sure why this works, but the compiler seems to like
it! :D
The example is intentionally as simple as it gets, but a "real" app
should probably return Result<Event, Error> from its handlers.
Signed-off-by: Jim Crossley <jim@crossleys.org>
Conditionally compile reqwest module when enabled
This resulted in a naming conflict between my desired feature name,
"reqwest", and the optional dependency itself. So I adopted the
convention of prefixing the features with "cloudevents-".
Signed-off-by: Jim Crossley <jim@crossleys.org>
Conditionally compile actix module when enabled
Mostly straightforward, though I don't particularly love that dev-deps
can't be optional: https://github.com/rust-lang/cargo/issues/1596
Signed-off-by: Jim Crossley <jim@crossleys.org>
Jim Crossley
Dejan Bosanac
andrew webber (personal)
Francesco Guardiani
Matthias Wessendorf
dependabot[bot]
Jens Reimann
Jens Reimann
tottoto