Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support channel image #8

Open
onli opened this issue Mar 3, 2019 · 3 comments
Open

Support channel image #8

onli opened this issue Mar 3, 2019 · 3 comments

Comments

@onli
Copy link
Contributor

onli commented Mar 3, 2019

RSS and Atom both support setting a channel image, with the three nodes url, title and link. See https://cyber.harvard.edu/rss/rss.html#ltimagegtSubelementOfLtchannelgt for the RSS side, and https://tools.ietf.org/html/rfc4287#section-4.2.8 for the Atom side (I think that's the best fit, but it seems to support just an URL). Maybe feedparser could be extended to carry the channel image around?

@geraldb
Copy link
Member

geraldb commented Mar 6, 2019

One idea is to easily support access to the full underlying structure with all its additions (in a uniform "parsed" way e.g. xml or json converted to a nested ruby hash, for example.

Also might be a good idea to check what feedjira https://github.com/feedjira/feedjira offers or how it handles channel images?

@onli
Copy link
Contributor Author

onli commented Mar 6, 2019

feedjira has a class for rss channel images in https://github.com/feedjira/feedjira/blob/master/lib/feedjira/parser/rss_image.rb/. I think it has no equivalents for atom and jsonfeed.

Having full access to the origin structure sounds very useful. Something like https://stackoverflow.com/a/10144623/2508518 could work, though I assume nokogiri is not an ideal requirement for this gem.

@geraldb
Copy link
Member

geraldb commented Mar 6, 2019

Thanks. Good points. Soon or later the "old" standard rss library has to get replaced with something better. Why not nokogiri? I'm all for it. The only downside as far as I can tell is the "hard-to-install" part because it requires a c-extension. The idea of the nested hash is that it is uniform, that is, the same for xml and json - thus, I'm not sure if the nokogiri .to_hash format (or is it just a "dump") is a 100% fit here. But yeah it's the same basic idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants