The commit named Change the License for MIT actually uploads Apache 2.0. Not sure if this is what you wanted to do, or just uploaded the wrong file.

It is common for Rust projects to specify license = "MIT OR Apache-2.0" as discussed here: https://rust-lang.github.io/api-guidelines/necessities.html
Probably this is what you wanted to do.

Create a list of tests

I open this issue to signal that the whole generator module is not visible in doc.rs. It took me a while to figure out that this library can also do calendar generation besides of parsing, so I think it could be useful to show it on the docs.

Many wording are not explicite.

It would be great of the changes get pushed to crate.io. Thank you!

Create a github wiki with Rust documentation

I think this a relatively common use-case (e.g. when retrieving data from a remote server), where one has a String – is it possible to parse these directly?

Thanks for this crate.

I wished it had a serde cargo feature, so that I could include e.g. parsed Propertys into my own structs that #[derive(Serialize)].

I can work around this by writing my own serializer (which is not terribly difficult), but it would be better if it was already included in your crate (I haven't really tried yet, but reading quickly into the serde documentation, it looks like the latter is more difficult than the former, so I'm not even sure I'll be able to do this myself and make a MR for this :-/ )

The first two lines of a Vcard/Ical file must specify the protocole and its versions as:

BEGIN:VCARD
VERSION:4.0

Goal

Read this first two lines and load automatically the corresponding design set

Some ics files I found in the wild contain DAYLIGHT and STANDARD subcomponents inside the VTIMEZONE component. It seems to be a valid RFC 5545:
https://tools.ietf.org/html/rfc5545#section-3.6.5

Right now ical-rs returns a parsing error InvalidComponent if this components are found. I don't need ical-rs to be able to parse them, but will be nice if it was more permissive and be able to parse this files.

Many function are not documented

Hi @Peltoche

It looks like property groups are not supported.

From the spec https://www.rfc-editor.org/rfc/rfc6350#section-3.3 on page 6:

...
   contentline = [group "."] name *(";" param) ":" value CRLF
...
   group = 1*(ALPHA / DIGIT / "-")
...

And then page 7:

The group construct is used to group related properties together.
The group name is a syntactic convention used to indicate that all
property names prefaced with the same group name SHOULD be grouped
together when displayed by an application. It has no other
significance. Implementations that do not understand or support
grouping MAY simply strip off any text before a "." to the left of
the type name and present the types and values as normal.

So having vCard property line:

gr1.FN:Bob

The expectation would be something like:

let p = vcard.get_property("FN").unwrap();
assert_eq!(p.name, "FN");
assert_eq!(p.group, Some("gr1"));

IMHO, the key point here is that the property name should be "FN" and not "gr1.FN".

Is this functionality being considered? I could submit a PR.

Cheers

I can't pass single events to other functions, because I can't reference the type IcalEvent by name, since it's in the private module “component”.

The same is true for everything else in ical::parser::ical::component except IcalParser, which is reexported from the top level module.

The current parameter parser in LineParser handle only the PARAM_DELIMITER (';') without escaping dquotes.

This input is not handled correctly:

NOTE;CN="Foo;Bar":This is a note

The input is valid but the current parser will try to split the parameter at the PARAM_DELIMITER, producing and error or invalid (key/param).
Possible output:

Params: Vec<("CN", "\"Foo"), ("Bar\", "")>

The linked documentation points to 0.3.0, which seems not to be the latest version of this crate.

The documentation for 0.4.0 over at docs.rs is missing some things, mainly the IcalCalendar type which is yielded by iterating over the IcalParser type, but maybe also more.

Should be acting like IcalParser and return a list of components. It should be easier as Vcard doesn't have recursive components.

Hi,

(I'm not sure whether you received notifications about my previous messages in closed issues, so I'm creating a new issue, sorry for the duplication).
Now you've merged #44 , could you release a 0.8 version?

That's because I'd like to use ical in my own crate, and I cannot publish my own crate with dependencies that are not published in crates.io (and I'd like to avoid publishing a "temporary" fork of your crate that I'll have to deprecate once you publish 0.8...)

Thanks

To reproduce, feed the parser any invalid UTF-8.

My test was

fuzz_target!(|data: &[u8]| {
    let c = std::io::Cursor::new(data);
    for _ in ical::IcalParser::new(c) {}
});

The iterator is already over Result's to indicate errors, so I would expect invalid UTF-8 to be just an Err yielded.

Hey-hey, would be lovely to have a bunch of extra derives on ical::parser::vcard::component::VcardContact per Rust API Guidelines Checklist.

I am particularly interested in the following traits:

• std::cmp::Eq
• std::cmp::PartialEq
• std::hash::Hash

Thanks <3

With the package log probably.

I recently encountered a panic when generating an iCal event, after a bit of debugging I found the function split_line to fail when the line break should be inserted at a multibyte character.

Here is a test code to demonstrate the issue:

fn main() {
   let s = "DESCRIPTION:ABCDEFGHIJ\\n\\nKLMNOPQRSTUVWXYZ123456789üABCDEFGHIJKLMNOPQRS\\n\\nTUVWXYZ123456ä7890ABCDEFGHIJKLM\\n\\nNOPQRSTUVWXYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWXöYZ1234567890ABCDEFGHIJKLMNOPQRSTUVWX\\n\\nYZ1234567890abcdefghiÜjklm\\nnopqrstuvwx".to_string();
   let r1 = split_line2(s.clone());
   println!("{}", r1);
}

It fails with:

thread 'main' panicked at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/string.rs:1688:9:
assertion failed: self.is_char_boundary(idx)
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

I will create a pull request with a different implementation, which is multibyte aware. Could you please check it out?

Thank you,

Ronny

I need a crate to parse ical more high level than just to properties.

I was basically thinking of something like:

struct VEvent {
start: Option<TimeStamp>,
end: Option<TimeStamp>,
summary: ...
// Unsuported Properties
properties: Vec<Property>,
}

Is this something that can be implemented in the scope of this crate, as a PR? Or should I create a high-level crate depending on ical-rs?

Hey @Peltoche

Is this library abandoned or feature-complete/stable?
Are there any known limitations, bugs? I stumbled upon this repo while looking for rust ical implementations.

With:

[dependencies]
ical = "0.2.0"

I get "Could not find IcalReader in ical" error using the example from the README:

extern crate ical;

use std::io::BufReader;
use std::fs::File;

fn main() {
    let buf = BufReader::new(File::open("/england-and-wales.ics")
        .unwrap());

    let reader = ical::IcalReader::new(buf);

    for line in reader {
        println!("{:?}", line);
    }
}

Which newbie mistake am I making?