pep/xmpp-rs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
xmpp-rs/xso/Cargo.toml

31 lines
1 KiB
TOML
Raw Normal View History

xso: create library for streamed XML parsing This library provides the traits to parse structs from XML and serialise them into XML without having to buffer the document object model in memory. The only implementations it provides are for minidom, basically providing a lower-level interface to `minidom::Element::from_reader` and `minidom::Element::to_writer`. This is the first stepping stone into a world where `xmpp_parsers` can parse the structs directly from XML.
2024-06-16 08:14:13 +00:00
[package]
name = "xso"
xso: Bump version to 0.1.0
2024-07-25 07:52:44 +00:00
version = "0.1.0"
xso: create library for streamed XML parsing This library provides the traits to parse structs from XML and serialise them into XML without having to buffer the document object model in memory. The only implementations it provides are for minidom, basically providing a lower-level interface to `minidom::Element::from_reader` and `minidom::Element::to_writer`. This is the first stepping stone into a world where `xmpp_parsers` can parse the structs directly from XML.
2024-06-16 08:14:13 +00:00
edition = "2021"
description = "XML Streamed Objects: similar to serde, but XML-native."
homepage = "https://xmpp.rs"
repository = "https://gitlab.com/xmpp-rs/xmpp-rs"
keywords = ["xmpp", "xml", "serialization"]
categories = ["encoding"]
license = "MPL-2.0"
[dependencies]
Bump rxml to 0.11.1
2024-06-29 12:33:01 +00:00
rxml = { version = "0.11.1", default-features = false }
Unify version string formats https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements "^1.2.3" is strictly equivalent to "1.2.3" Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
2024-07-25 08:34:39 +00:00
minidom = { version = "0.16" }
xso: Bump version to 0.1.0
2024-07-25 07:52:44 +00:00
xso_proc = { version = "0.1", optional = true }
xso-proc: start making derive macros for FromXml and IntoXml For now, these macros only support empty elements. Everything else will be rejected with a compile-time error.
2024-06-21 15:53:37 +00:00
xso: add support for base64 text codec
2024-06-26 16:36:48 +00:00
# optional dependencies to provide text conversion to/from types from/using
# these crates
xso: add traits for XML text <-> value conversion The traits have undergone a couple iterations and this is what we end up with. The core issue which makes this entire thing ugly is the Orphan Rule, preventing some trait implementations relating to types which haven't been defined in this crate. In an ideal world, we would implement FromXmlText and IntoXmlText for all types implementing FromStr and/or fmt::Display. This comes with two severe issues: 1. Downstream crates cannot chose to have different parsing/serialisation behaviour for "normal" text vs. xml. 2. We ourselves cannot define a behaviour for `Option<T>`. `Option<T>` does not implement `FromStr` (nor `Display`), but the standard library *could* do that at some point, and thus Rust doesn't let us implement e.g. `FromXmlText for Option<T> where T: FromXmlText`, if we also implement it on `T: FromStr`. The second one hurts particularly once we get to optional attributes: For these, we need to "detect" that the type is in fact `Option<T>`, because we then need to invoke `FromXmlText` on `T` instead of `Option<T>`. Unfortunately, we cannot do that: macros operate on token streams and we have no type information available. We can of course match on the name `Option`, but that breaks down when users re-import `Option` under a different name. Even just enumerating all the possible correct ways of using `Option` from the standard library (there are more than three) would be a nuisance at best. Hence, we need *another* trait or at least a specialized implementation of `FromXmlText for Option<T>`, and we cannot do that if we blanket-impl `FromXmlText` on `T: FromStr`. That makes the traits what they are, and introduces the requirement that we know about any upstream crate which anyone might want to parse from or to XML. This sucks a lot, but that's the state of the world. We are late to the party, and we cannot expect everyone to do the same they have done for `serde` (many crates have a `feature = "serde"` which then provides Serialize/Deserialize trait impls for their types).
2024-06-25 15:36:36 +00:00
# NOTE: because we don't have public/private dependencies yet and cargo
# defaults to picking the highest matching version by default, the only
# sensible thing we can do here is to depend on the least version of the most
# recent semver of each crate.
Unify version string formats https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements "^1.2.3" is strictly equivalent to "1.2.3" Signed-off-by: Maxime “pep” Buquet <pep@bouah.net>
2024-07-25 08:34:39 +00:00
jid = { version = "0.11", optional = true }
uuid = { version = "1", optional = true }
base64 = { version = "0.22", optional = true }
xso: add traits for XML text <-> value conversion The traits have undergone a couple iterations and this is what we end up with. The core issue which makes this entire thing ugly is the Orphan Rule, preventing some trait implementations relating to types which haven't been defined in this crate. In an ideal world, we would implement FromXmlText and IntoXmlText for all types implementing FromStr and/or fmt::Display. This comes with two severe issues: 1. Downstream crates cannot chose to have different parsing/serialisation behaviour for "normal" text vs. xml. 2. We ourselves cannot define a behaviour for `Option<T>`. `Option<T>` does not implement `FromStr` (nor `Display`), but the standard library *could* do that at some point, and thus Rust doesn't let us implement e.g. `FromXmlText for Option<T> where T: FromXmlText`, if we also implement it on `T: FromStr`. The second one hurts particularly once we get to optional attributes: For these, we need to "detect" that the type is in fact `Option<T>`, because we then need to invoke `FromXmlText` on `T` instead of `Option<T>`. Unfortunately, we cannot do that: macros operate on token streams and we have no type information available. We can of course match on the name `Option`, but that breaks down when users re-import `Option` under a different name. Even just enumerating all the possible correct ways of using `Option` from the standard library (there are more than three) would be a nuisance at best. Hence, we need *another* trait or at least a specialized implementation of `FromXmlText for Option<T>`, and we cannot do that if we blanket-impl `FromXmlText` on `T: FromStr`. That makes the traits what they are, and introduces the requirement that we know about any upstream crate which anyone might want to parse from or to XML. This sucks a lot, but that's the state of the world. We are late to the party, and we cannot expect everyone to do the same they have done for `serde` (many crates have a `feature = "serde"` which then provides Serialize/Deserialize trait impls for their types).
2024-06-25 15:36:36 +00:00
xso-proc: start making derive macros for FromXml and IntoXml For now, these macros only support empty elements. Everything else will be rejected with a compile-time error.
2024-06-21 15:53:37 +00:00
[features]
macros = [ "dep:xso_proc" ]
minidom = [ "xso_proc/minidom"]
panicking-into-impl = ["xso_proc/panicking-into-impl"]
Reference in a new issue Copy permalink