[MGNLRSSAGG-40] As a user I can import media attachements along with RSS entries. Created: 12/Nov/10  Updated: 04/Nov/15  Resolved: 04/Nov/15

Status: Closed
Project: Magnolia RSS Aggregator Module
Component/s: rss_importer
Affects Version/s: 1.1.1, 1.1.2, 1.1.3, 1.2, 1.2.1
Fix Version/s: 2.2.x

Type: Story Priority: Major
Reporter: Lutz Hühnken Assignee: Unassigned
Resolution: Won't Do Votes: 1
Labels: enclosure, next, rss, rssaggregator
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File enclosures.patch    
Template:
Patch included:
Yes
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

RSS enclosures are a way of attaching multimedia content to RSS feeds by providing the URL of a file associated with an entry, such as an MP3 file to a music recommendation or a photo to a diary entry. (See "http://en.wikipedia.org/wiki/RSS_enclosure").

The mapping from SyndEntry to content node seems to be done in

info.magnolia.module.rssaggregator.importhandler.RSSFeedImportHandler.createFeedChannelEntryNode(SyndEntry, String, Content)

The method does not store any enclosures in the node. I suggest to extend it to store enclosures as well.



 Comments   
Comment by Magnolia International [ 18/Nov/10 ]

Hi Lutz,

Is there any chance you could provide a patch for this ? That'd certainly help seeing this feature be added to the codebase faster
Even drafts or code snippets would help. The more complete (incl. test), the better chances that this gets added to the next release, though

Comment by Lutz Hühnken [ 18/Nov/10 ]

What would be the desired behaviour?

The enclosure does not contain the actual payload, it provides an URI and a mime type. Should the actual content that is referred (image, mp3..) be prefetched and stored in the JCR?

Or should one just store the link & mime-type (i.e. the actual xml attributes of the enclosure element) of the enclosure in the JCR and leave it to the rendering paragraph to fetch (or not fetch) them?

Comment by Jan Haderka [ 18/Nov/10 ]

I guess the best would be to have both and make it configurable.
If not then storing the link and mime type is the right solution since the content might get big in case of podcasts and could increase load on the instance significantly if streamed out multiple times without server being able to do the multicast.
Even if both would be possible, the link + mime type should be the default config.

Comment by Lutz Hühnken [ 22/Nov/10 ]

I attached a little patch that will, if the entry contains enclosures,

  • create an "enclosures" node
  • create a child node for every enclosure with the attributes length, type, url

This is what I need for my current use case and I don't think it will cause any harm to anyone else, since it does not download / store the actual enclosure, just the information included in the original entry.

The patch was created for the trunk (revision 39447).

Comment by Jan Haderka [ 22/Nov/10 ]

excellent. thanks a lot. I'll look into it as soon as i get back to office (in a week).

Comment by Lutz Hühnken [ 01/Jun/11 ]

Updated the affected versions to reflect the fact that this still applies to the current version of rss aggregator.

Comment by Michael Mühlebach [ 04/Nov/15 ]

Given the thousands of other issues we have open that are more highly requested, we won't be able to address this issue in the foreseeable future. Instead we will focus on issues with a higher impact, and more votes.
Thanks for taking the time to raise this issue. As you are no doubt aware this issue has been on our backlog for some time now with very little movement.
I'm going to close this to set expectations so the issue doesn't stay open for years with few updates. If the issue is still relevant please feel free to reopen it or create a new issue.

Generated at Mon Feb 12 07:04:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.