From: http://www.rssboard.org/rss-specification#ltenclosuregtSubelementOfLtitemgt
<enclosure> is an optional sub-element of <item>. It has three required attributes. url says where the enclosure is located, length says how big it is in bytes, and type says what its type is, a standard MIME type. The url must be an http url.
<enclosure url="http://www.scripting.com/mp3s/weatherReportSuite.mp3" length="12216320" type="audio/mpeg" />
generate feeds may have useful background/thoughts.
--John Abbe.....Wed Mar 02 15:33:05 -0800 2011
the solution(s) above only address the "url" piece. How would we handle the "length" and "type"? I'm not personally able to spend the time to build a system that autodetects all that from a remote source. Not in the near term, at least.
--Ethan McCutchen.....Tue Oct 25 08:08:43 -0700 2011
Ouch on pushing this to later - I know it's work you're not getting paid for, but this is something we promised Jerry late last year would be in the next release...
It shouldn't be that hard to get length and mime-type from the paperclip attachments interface. It has me thinking again about how to do Active Card Model in a more bidirectional way. I was thinking mainly of mapping Card[Gerry+*account].email to and from cards (i.e. Card[Gerry+*account+*email] and optionally by declaration Card[Gerry+*email] to/from Card[Gerry+*account].email), but maybe we want Card[BlogEntry+Attachment+*length] (and ...+*mime-type) to what are really 'virtual' plus cards that give the underlying value from the special model attributes associated with all attachement cards.
Glad to see your input on this, Gerry. I'm really hoping we can get this into the next release, let me know if there's anything I can do to help with that.
the site that wants this (yi-tan.com) is not using attachments; it's using remote urls.
We could research/test if podcast-reading software really breaks if length and/or type are not given. If either do, then we could tell Jerry that they have to move the mp3s to Wagn :-P if we don't come up with some clever way to get the metadata from remote urls.
Well, then you could get that information by issuing a request to the URI. For sure you should be able to get the type that way, but content-length is an optional header field. If it is there you can get it. I think this is a case for using a HEADERS request. Then we would have the problem of how to save that data so we don't have to redo that request all the time.
I wonder just how "required" the other two fields are, particularly length.
Yeah, I kind of remember seeing that we might be able to get away with doing 0 length. My inclination is to do this as a hacky module for yi-tan and see what we can get to work.
Very cool - thx for doing this.