support enclosures in feeds



You can upload files to cards that are plussed off of blog entries, but out feeds don't yet XML-tag them in a way that will be understood as a podcast.


No generalized solution yet.  Just built a custom module for yi-tan for now, which adds an enclosure to call cards when there is a +podcast card present.




<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="" 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...

--John Abbe.....2013-04-15 08:15:58 +0000

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 Cards Models 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.

--Gerry Gleason.....2013-06-08 18:38:36 +0000

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.

--John Abbe.....2013-06-09 04:13:26 +0000

the site that wants this ( is not using attachments; it's using remote urls.

--Ethan McCutchen.....2013-06-10 05:19:15 +0000

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.

--John Abbe.....2013-06-10 08:26:54 +0000

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.

--Gerry Gleason.....2013-06-10 10:57:45 +0000

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.

--Ethan McCutchen.....2013-06-10 15:28:44 +0000

Very cool - thx for doing this.

--John Abbe.....2013-09-17 05:03:30 +0000