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.
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.
It was broken in multiple ways:
- xso did not honour it: unknown children and attributes would cause a
parse error even with `--features disable-validation` set on parsers.
For this, we introduce a new feature flag on xso, `non-pedantic`,
which defaults unknown children and attributes to discard instead of
fail.
Note that individual XSOs can still choose to be always pedantic or
always lenient by explicitly declaring the intent via the
`on_unknown_child` and `on_unknown_attribute` metas.
- Many tests in `xmpp_parsers` were broken with `--features
disable-validation`. They now all pass while *still* being rn with
`disable-validation` set: In that case, they test that parsing in fact
succeeds.
Let’s continue reexporting jid and minidom, but not their inner pub
items, users of this crate can go one level deeper if they need that.
Only xso::error::Error is still useful to reexport, as this is part of
the public API of all of our parsers.
This is a large change and as such, it needs good motivation. Let me
remind you of the ultimate goal: we want a derive macro which allows us
to FromXml/IntoXml, and that derive macro should be usable from
`xmpp_parsers` and other crates.
For that, any code generated by the derive macro mustn't depend on any
code in the `xmpp_parsers` crate, because you cannot name the crate you
are in portably (`xmpp_parsers::..` wouldn't resolve within
`xmpp_parsers`, and `crate::..` would point at other crates if the macro
was used in other crates).
We also want to interoperate with code already implementing
`TryFrom<Element>` and `Into<Element>` on structs. This ultimately
requires that we have an error type which is shared by the two
implementations and that error type must be declared in the `xso` crate
to be usable by the macros.
Thus, we port the error type over to use the type declared in `xso`.
This changes the structure of the error type greatly; I do not think
that `xso` should have to know about all the different types we are
parsing there and they don't deserve special treatment. Wrapping them in
a `Box<dyn ..>` seems more appropriate.
Looking at [the spec](https://xmpp.org/extensions/xep-0004.html#protocol-field)
it seems valid not to have a `var` attribute set, at least for fields of type
`fixed` that is:
> If the element type is anything other than "fixed" (see below), it MUST
> possess a 'var' attribute that uniquely identifies the field in the context
> of the form (if it is "fixed", it MAY possess a 'var' attribute). The element
> MAY possess a 'label' attribute that defines a human-readable name for the field.
Version 0.21 replaced base64::decode() with an Engine trait and multiple
structs implementing it for various alphabets, various performance
profiles, etc. It is slightly longer to import but in the end does the
very same thing.
