Crates.io | sdp-nom |
lib.rs | sdp-nom |
version | 0.2.0 |
source | src |
created_at | 2022-01-14 23:20:28.405674 |
updated_at | 2022-11-03 21:37:17.086635 |
description | an sdp-parser |
homepage | |
repository | https://github.com/hoodie/sdp-nom |
max_upload_size | |
id | 514114 |
size | 161,184 |
This is a nom-based SDP parser.
It can parse and reserialize and is currently optimized for a very small wasm footprint (hence the use of ufmt).
You don't need reserialization? Just build with --no-default-features
.
There is already mozilla's webrtc-sdp, sdp from webrtc.rs and sdp-types, which are all very good, why make another? This is still very much a "for fun" project, so don't mind me!
name | what it does | default |
---|---|---|
udisplay | use ufmt to reserialize session and lines | yes |
debug | provide Debug formatting for all types |
yes |
serde | well serde support of course | no |
wee | use wee allocator | no |
With this parser we try to implement a wasm-friendly, low-copy and high-level-nom parser.
By using wee and ufmt we try to achieve a small binary size. Further Debug-printing is a feature that can be disabled. Further concrete wasm-related work is on the horizon.
Zero copy seems a bit out of reach but this parser tries to enable as much as possible without actually copying over the content of the sdp.
This is achieved by reading any string into a Cow
and only optionally creating a 'static
copy of the content.
SDP is a weird standard,
there is no container format specification other than that lines start with a char
followed by =
.
Basically every line follows it's own rules.
Therefore every line has its own parser like in this example:
/// Email `e=<email-address>`
pub struct EmailAddress<'a>(pub Cow<'a, str>);
/// "e=email@example.com"
pub fn email_address_line(input: &str) -> IResult<&str, EmailAddress> {
line("e=", wsf(map(cowify(read_string), EmailAddress)))(input)
}
icalendar-rs is licensed under either of
at your option.
Any help in form of descriptive and friendly issues or comprehensive pull requests are welcome!
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in sdp-nom by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.