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>
XEP-0167 has been updated to version 1.2.3, to change the type of the
'ssrc' attribute to u32 (from String). This is in accordance with
RFC 3550 (RTP), which defines it as a randomly-chosen 32-bit unsigned
integer.
Additionally, the docstring was completely wrong.
It may not matter much for the moment as this struct shouldn't change
very much during the life of the client, but this prevents the lock from
being held too long.
Signed-off-by: pep <pep@bouah.net>
From the prosody@ room:
- 0114 doesn't mention the removal of @version on the stream, and it
refers to 3920 which has it as a MUST.
- 0114 streams have historically never used @version="1.0"
- @version="1.0" implies stream features which 0114 doesn't have.
- There was a proposal years ago to fix this but a new XEP was preferred
(0225).
The change here uses a compile-time check, and may have to change when
support for 0225 arrives if it's still gated behind the "component"
feature (even though it may be weird to have both under the same
feature). We'll see when we get there.
Signed-off-by: pep <pep@bouah.net>
