282174 - Add Podcasting Support

Status: RESOLVED FIXED

(MailNews Core :: Feed Reader, defect)

Description

[Scott MacGregor]

We should represent RSS enclosures in feed articles as if they were e-mail
attachments. Opening the attachment should cause us to open the URL for the
enclosure (or send the URL to the OS for handling, not sure which yet).

Comment 1

[Scott MacGregor]

I've got a prototype of this up and working. I need to cleanup some of it then
I'll post a patch. 

Comment 2

[Scott MacGregor]

Attachment: initial implementation

Comment 3

[Scott MacGregor]

David, I noticed that MIME had an argument for an attachment that was getting
passed around called notDownloaded (defined in nsIMsgSend::nsMsgAttachment
struct). We passed this flag from the HTML mime emitter out to the
msgHdrViewOverlay header sink class. It was set whenever we were dealing with an
imap part that hadn't been fetched yet. But I was unable to find any consumer
that actually looked at that flag (I did a search in mailnews on notDownloaded).
We were just passing it around.

So I usurped that argument, removed the two places in libmime where we were
setting it to true for IMAP and am now using it as a flag for whether the
attachment is an enclosure (where enclosure means the attachment is just a URL
reference that points to the location of the real attachment). 

Questions/Comments:
1) Support for a separate attachment store could use this code as well
obviously, setting a file url as the enclosure URL. 
2) Do you see something I may have missed where someone is using the
notDownloaded flag?
2) Are you happy with sharing the word "enclosure" in the code for attachments
and this RSS piece? Or should I come up with a better word.
3) If you are happy with the word enclosure, I think I should rename all of the
variables in libmime and in the UI where we pass around notDownloaded -->
isEnclosure

Comment 4

[Scott MacGregor]

Attachment: the fix

Adds support for RSS enclosures to Thunderbird.

Currently, we just send the URL to the OS and let it figure it out by altering:


function openAttachment(aAttachment)
{
  if (aAttachment.isExternalAttachment)
    messenger.launchExternalURL(aAttachment.url);
  else
    messenger.openAttachment(aAttachment.contentType, 
			     aAttachment.url, 
			     encodeURIComponent(aAttachment.displayName), 
			     aAttachment.messageUri);
}

This is fine for a first cut I think. But eventually I'd like us to actually
open the URL ourselves and send it to the helper app dialog instead of relying
on the browser to do that for us. This could mean modifying our implementation
of nsMessenger::OpenAttachment/SaveAttachment to handle the
isExternalAttachment flag and do the right thing....

Currently hooked up only for RSS 2.0 feeds. I haven't found any examples on the
web yet for other RSS types to test against. Once I do, I'll add support for
those too.

Renames the unused notDownloaded flag in libmime to isExternalAttachment so we
can share it with the stripped attachment code down the line. 

Fixed some tabs in nsIMimeMiscStatus.idl 

Note: there were no interface changes in this patch so no IIDs are bumped.

Comment 5

[Scott MacGregor]

Attachment: better fix that opens that brings up the helper app dialog

Same patch as before, except I passed in the external attachment flag into
nsIMessenger::OpenAttachment/SaveAttachment. These two routines now look at
this flag and call OpenURL if the flag is true. This causes us to start opening
the external attachment url ourselves and when we discover we can't handle it,
we kick open the helper app dialog. This is a much better experience than
sending the url to your browser and then having it bring up the dialog as it
behaves more like an attachment.

Comment 6

[Scott MacGregor]

Comment on attachment 174326 [details] [diff] [review]
the fix 

cancel review of obsolete patch

Comment 7

[(not reading, please use [e-mail] instead)]

a=sspitzer for 1.8b

Comment 8

[Scott MacGregor]

fixed, I'm sure we'll have to do more later to support things like
SaveAllAttachments and probably some more MIME changes once the code for storing
attachments in a separate location comes online but this gets us going.

Would eventually like to support multiple enclosures per feed but again, I
haven't seen an example of that in the wild yet to test against. 

Comment 9

[Jeffrey Bacon]

Why is this integrated into the core of Thunderbird?  Shouldn't this be an
extension?  There are many other features that more people would benefit from
than podcasting support.

Comment 10

[Ray Trent]

Re: comment 9, I would argue that RSS feeds of blogs are the modern equivilent
of newsgroups, and as such an email/newsreader program should do a good job of
handling them natively. 

Comment 11

[Jeffrey Bacon]

since TB can't view the content of these feeds (audio) it's a little different
than a text-based messaging platform (eg. email, nntp, news-rss).  Unless
there's native support for playing the audio in TB... I'm sure no one wants a
full audio player in TB... and even then, nntp support extends to pictures and
text.  Not video and audio.  Why support audio RSS feeds but not audio from nntp
message?

wait, you're probably going to argue that the audio files are attachments to the
RSS items in the podcast feeds, and that's just like the binary attachments on
nntp or mail messages.  However I think we need to consider the use of the
podcasts.  People use nntp/mail/news-rss to read messages.  Granted my knowledge
of podcasting is limited, but anytime podcasting is referenced, it's referenced
in the context of listening to content.  Syncing with an audio player or saving
the audio to disk to listen to.

It's more about the intentions of the medium. Podcasting is delivering audio and
the rss attaches a brief description of the main content (audio).

You could argue news-rss is the same, a brief textual description of a link, but
I make a distinction because the content of a news-rss feed is viewable in TB
itself.

Comment 12

[will mooney]

Forgive me for re-opening this but there is an active discussion about this in 
the build forum for TB on Mozillazine. I think you should be careful about 
using the term podcasting for the current feature set of TB because in its 
current form, it is not true. TB needs to be able to automatically download the 
attachement (audio) into a predefined store so that the user can then upload to 
his/her music player. 

If you are not going to change the current functionality I think you should re-
word the description of this feature. You'll just get flamed by the likes of 
ipodder makers etc etc.

podcasting is a killer feature, if it's done right it will win TB some big 
Brownie points :)