While the FromXml bound is necessary for the key implementation of the
XmlStream (the `impl Stream`), the AsXml bound is not as intrinsic: the
Sink implementation can take any AsXml implementation on each separate
send invocation.
By removing this bound, we can add extra logic *only* to the parsing,
without having to worry about effects on the sending side.
Concretely, we'll be able to create a wrapper type for XmppStreamElement
which allows us to capture errors during parsing, without having to
worry about what happens during serialisation.
Adds an option to split the `tokio-xmpp::Client` into a Sender and
Receiver. To enable this, a client worker is added which drives the
stream in the background.
Up to now, the xmpp-rs projects have been very strict about incoming
data. This has served us, as developers of the libraries, well,
uncovering bugs in our and remote implementations which we could then
get fixed.
However, this behaviour is unexpected to users of the library. In the
XMPP world, unexpected child elements and attributes are generally
expected to be ignored. While this could be opted-into previously, the
feature flag for that sounded more dangerous than it was
("disable-validation"). In addition, the tribal knowledge needed to know
about that feature flag may not have reached some people who tried the
library and gave up because of that.
With this change, we make the non-pedantic behaviour the default. For
development and debugging purposes, users can always opt into the
pedantic behaviour as needed, using the newly-introduced `pedantic`
feature flags on all affected crates.
This disables a bunch of tests when the component feature is disabled,
because that feature changes the namespace of the <message/> element,
which causes the tests to fail.
Thanks to debacle for finding this.
Features must never be duplicated, so we can use a BTreeSet instead of a
Vec to be nicer for users.
It makes the internal API for computing caps and ecaps2 a bit worse,
because it was expecting a slice directly, so for now let’s collect the
BTreeSet into a Vec when computing the thing. A refactor to use
Iterator might make it better eventually, but I won’t work on that
before profiling it.
This was already just a wrapper around a Vec<String>, but we can do away
with the wrapper thanks to #[xml(extract)].
I’ve also replaced Vec with BTreeSet, since that corresponds better to
how the mechanisms are.
It's great for debugging for fast-paced implementations but the codebase
has been more or less the same for years now (in a state we don't
exactly like, but it is what it is) and this is hindering things more
than helping.
Keep it at the INFO level nonetheless to make it more or less obvious
these things are not implemented.
Signed-off-by: pep <pep@bouah.net>
This should have been done in 19865e5f probably, before the latest
release. This generally causes users of the library to cargo update
manually.
Signed-off-by: pep <pep@bouah.net>
