--- 4 янв. 2023 г.

The atom_syndication::Error type can't be automatically converted to failure::Error by the failure crate. I'm not entirely sure why; the compile error is below if it helps. I don't have this issue with the RSS crate, which is already using failure for its errors. Currently I have to work around this by explicitly converting the error to a string before using the ? operator.

    |
183 |     let atom_feed : AtomFeed = text.parse()?;
    |                                ^^^^^^^^^^^^^ `std::error::Error + std::marker::Send + 'static` cannot be shared between threads safely
    |
    = help: the trait `std::marker::Sync` is not implemented for `std::error::Error + std::marker::Send + 'static`
    = note: required because of the requirements on the impl of `std::marker::Sync` for `std::ptr::Unique<std::error::Error + std::marker::Send + 'static>`
    = note: required because it appears within the type `std::boxed::Box<std::error::Error + std::marker::Send + 'static>`
    = note: required because it appears within the type `std::option::Option<std::boxed::Box<std::error::Error + std::marker::Send + 'static>>`
    = note: required because it appears within the type `error_chain::State`
    = note: required because it appears within the type `quick_xml::errors::Error`
    = note: required because it appears within the type `atom_syndication::Error`
    = note: required because of the requirements on the impl of `failure::Fail` for `atom_syndication::Error`
    = note: required because of the requirements on the impl of `std::convert::From<atom_syndication::Error>` for `failure::Error`
    = note: required by `std::convert::From::from`

I'd be happy to submit a pull request if you'd like, but I think that might require a breaking change.

It seems there are no typed date or time in this crate, for example, Feed#updated, Entry#updated and Entry#published.

Should we replace String with ::chrono::DateTime<::chrono::FixedOffset>? with typed field, there will be less confusion.

I'm going to do this, I think this crate is excellent, It is my honor to participate in this project.

I'm not native speaker, I believe that there are many errors in my narrative, please forgive me.

I want to use html entities in entry titles, but this requires type="html" as an attribute of the title tag, e.g.:

<title type="html"><![CDATA[ theses and objectives about decentralized systems &mdash; a collection ]]></title>

لانه تم تغيير معلومات حسابي فيس بوك ولا استطيع الوصول الى بريد الالكتروني الجديد ولكن لدي رسائل البريد الالكتروني القديم الخاص بالحساب
https://www.facebook.com/profile.php?id=100015363047007
| مراجع

#56 #59 لانه تم تغيير معلومات حسابي فيس بوك ولا استطيع الوصول الى بريد الالكتروني الجديد ولكن لدي رسائل البريد الالكتروني القديم الخاص بالحساب https://www.facebook.com/profile.php?id=100015363047007 | مراجع

Using HTML within a Content seems to include it verbatim in the output. This causes validation warnings at best, and broken XML at worst (e.g. .value("</content>".to_owned())).

I would expect the library to escape the content as text, unless I'm misunderstanding the Atom spec

For example https://headcrab.rs/feed.xml

I think this would make sense for stuff like Feed, Entry, and others. Would a PR for this be accepted?

No stop no

تم اختراق حسابي على فيس بوك

Currently it's possible to set namespaces, but not the default namespace, which also isn't emitted on the <feed> element.

It seems like a lack of the default namespace attribute gives Firefox trouble when detecting Atom feeds.

Building an Atom feed currently incurs many many allocations. Nearly every field of the type contains a String which mandates it be a separate and unique heap allocation. What's more, since all the .build() methods take &self they mandate cloning every single field in the builder. I think it would be good if atom_syndicator exposed a separate *Writer API for enabling feed-building without allocations. A sketch of what the API could look like is below:

pub struct FeedWriter<W> { /* ... */ }

impl<W: Write> FeedWriter<W> {
    pub fn from_writer(writer: W) -> Self { /* ... */ }

    pub fn title(&mut self) -> Result<TextWriter<'_, W>, Error> { /* set up the opening of a text tag */ }
    pub fn id<Id: Display>(&mut self, id: Id) -> Result<&mut Self, Error> { /* ... */ }
    // etc

    // Automatically runs in the destructor of `FeedWriter`, but can be called here to handle errors.
    pub fn finish(self) -> Result<W, Error> { /* ... */ }
}

pub struct TextWriter<'a, W: Write> { /* ... */ }

impl<W: Write> TextWriter<'_, W> {
    pub fn set<Value: Into<Text>>(self, text: Value) -> Result<(), Error> { /* ... */ }
    pub fn value<Value: Display>(&mut self, value: Value) -> Result<&mut Self, Error> { /* ... */ }
    pub fn base<Base: Display>(&mut self, base: Base) -> Result<&mut Self, Error> { /* ... */ }
    // etc
}

impl<W: Write> Drop for TextWriter<'_, W> {
    fn drop(&mut self) {
        // finish writing out the text tag

        // In lieu of fallible destructors, errors from here can be pushed
        // up into the FeedWriter and returned on the next call to any one
        // of its methods.
    }
}

Such an API would be usable like so:

let mut feed = FeedWriter::new(Vec::new());
feed.title()?.value("My example feed")?;
feed.id("http://example.com/")?;
feed.generator()?.value("My generator")?.version("1.0.0")?;
for entry in ["entry 1", "entry 2"] {
    feed.entry()?.content()?.value(entry)?;
}
let bytes = feed.finish()?;

As an alternative design, it's possible to collate all errors within the FeedWriter so that each individual method doesn't return a Result, but instead the first error is returned at .finish(). However that would mean it could force the user to do a lot more work than they need to do, since early returns on error conditions would not be possible.

Would such an API be possible to implement?

قامو باختراق حسابي الفيس وتغيرت المعلومات https://www.facebook.com/profile.php?id=100015363047007

(at least disable the clock feature, because of chronotope/chrono#499, which makes auditing more cumbersome, checking if a feature is disabled is easier than needing to grep all the code)

e.g.

[dependencies.chrono]
version = "0.4"
default-features = false
features = ["alloc"]

RFC 4287 §2 says:

Any element defined by this specification MAY have an xml:base attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an Atom Document, it serves the function described in section 5.1.1 of [RFC3986], establishing the base URI (or IRI) for resolving any relative references found within the effective scope of the xml:base attribute.

However, this crate doesn't let me set xml:base on <content>. It'd be nice to have such capability.

Issues and pull-requests are staying unaddressed for months. The same with rss crate.

atom_syndication::Error current has a variant Xml containing a quick_xml::Error. This has three negative impacts on the versioning of this library:

1. atom_syndication can't upgrade the version of quick_xml used internally without making a public API breaking change.
2. atom_syndication can't change which library it uses for XML parsing without making a public API breaking change.
3. As per C-STABLE, atom_syndication can never release 1.0.0 until quick_xml has also released 1.0.0.

The From<quick_xml::Error> for Error impl needs to go as well to avoid this problem.

To avoid this issue, atom_syndication should provide its own XmlError type that newtypes quick_xml::Error:

pub struct XmlError(quick_xml::Error);

Alternatively, XmlError can be an enum that has all the same variants as quick_xml::Error which would allow for easier introspection, but is quite verbose to define.

Hi, nice project. I was wondering if it would be possible to either support user-defined attributes on the <feed> and <entry> tags, such as xml:lang="en", or maybe it would be best to have a "lang" ("language"?) field somewhere (in Feed and Entry).

The xml:lang attribute is mentioned in Introduction to Atom - About this document which links to 2.12 Language Identification. Static Site Generators such as Zola also make use of this attribute (but I'd like to move away from it), so it would be nice if this crate somehow offered the possibility of setting the document's language. In the future, we could also decide what to do with the hreflang attribute.

I took a look at both the documentation and the code, but as far as I can tell, I'm only able to define namespaces and not actually arbitrary attributes for the <feed> tag. Thank you.

Fields of types like Feed have:

• Immutable getters (like fn title(&self) -> &str), and
• Setters (like fn set_title(&mut self, title: ...))

They works fine most of the time, but when you want to get an owned String from a Feed, you have to clone a &str returned by the setter, rather than just taking the ownership out of the Feed.

If Feed had mutable getters like fn title_mut(&mut self) -> &mut String, you could take the field without cloning:

use std::mem;
use atom_syndication::Feed;

let mut feed = Feed::default();
feed.set_title("Feed Title");
let title = mem::take(feed.title_mut());
assert_eq!(title, "Feed Title");
assert_eq!(feed.title(), "");

If the idea seems fine to you, I'd love to make a pull request (to this repository and rust-syndication/rss).

The crate stopped to parse feeds with non-conformant date fields.
Example feed

There was a possibility to loosely parse date fields with custom code (or just skip them). But now the whole feed is discarded with error WrongDatetime.

After the merge of #37, XHTML in Text elements are deserialized correctly (or at least seem to be), but the serialization does not handle XHTML specifically, which, other than HTML, does not need to be escaped, and shouldn't be, thus, the serialization for elements with type TextType::Xhtml is incorrect.

The current implementation of Display for Error forwards to the inner type's implementation of Display if there is one. However, it is preferable not to do this, for two reasons:

1. if the user wants the string representation of the inner error, they can always call .source()?.to_string() instead.
2. When formatted with tools such as Anyhow, the error message ends up duplicating the same information twice, e.g.:

Error: failed to refresh syndication feeds

Caused by:
0: incomplete utf-8 byte sequence from index 5
1: incomplete utf-8 byte sequence from index 5

It would be better if the error displayed what went wrong instead of why it went wrong, producing more helpful traces like this:

Error: failed to refresh syndication feeds

Caused by:
0: failed to parse Atom feed
1: incomplete utf-8 byte sequence from index 5

Now the error message tells a very clear and unambiguous story of exactly what happened. It makes it much easier to debug and is more friendly for users.

Note that this applies even to variants other than Error::Utf8 and Error::Xml. For example, the trace of an Error::Eof would better look like this:

Error: failed to refresh syndication feeds

Caused by:
0: failed to parse Atom feed
1: unexpected end of input

Than what it currently looks like:

Error: failed to refresh syndication feeds

Caused by:
0: unexpected end of input

What had an unexpected end of input? The error doesn't tell you.

The improved trace can be implemented by having source() return a new (potentially private) type EofError which Displays as "unexpected end of input".