podcasting
Scott Merrill
touched it up and put it in the -extras repository, and Ali added some
tweaks. Thanks!
http://trac.habariproject.org/habari-extras/browser/plugins/rss/rss.plugin.php
This is the first piece of the successful podcasting puzzle. The RSS
plugin triggers plugins prior to sending the RSS output with this:
"$xml= Plugins::filter( 'rss_feed', $xml );"
I propose that we create a new plugin called "podcast" that does the following:
* registers a new content type called podcast
* modifies the post composition screen to include a field in which one
places the URL to the podcast file they're publishing
* filters the RSS output to include the enclosure data for the media,
as well as inject all the necessary iTunes bits.
(If there are other things to do, please let me know -- I'm not a podcaster.)
The second step is one we've talked about in the abstract several
times, but I don't think we yet have code to permit the addition of
arbitrary fields on the post composition screen. (If we already have
such functionality, then I've been asleep at the wheel.)
What considerations should be in mind as we move forward on this functionality?
Cheers,
Scott
Owen Winkler
>
> I propose that we create a new plugin called "podcast" that does the following:
> * registers a new content type called podcast
> * modifies the post composition screen to include a field in which one
> places the URL to the podcast file they're publishing
And later:
> The second step is one we've talked about in the abstract several
> times, but I don't think we yet have code to permit the addition of
> arbitrary fields on the post composition screen. (If we already have
> such functionality, then I've been asleep at the wheel.)
I was thinking that we'd have a separate template for this purpose. It
should be easy to do, whereas adding arbitrary fields to the existing
composition template (as I imagine you'd have to do it, anyway) would be
unwieldy to maintain. I'll explain briefly.
It should be possible if it's not already done to extract the
surrounding components of the composition fields (the media browser and
the advanced area) into their own templates that are included from the
composition page. This should make it easy to create a new template
just for podcast posts that contains only those essential fields.
An alternative would be more complex because it would require that we
insert hooks in various places in that template. If a hook didn't exist
where a plugin might want to add a field, then we'd need to add new
ones, perhaps leading to many fields like "above_title" or "under_tags".
This doesn't strike me as a system we would want to maintain, when a
plugin could easily change out the form en masse using the method
describe above, and use the tab sections to house addtional fields for
existing content types.
A far different alternative would be to use FormUI to build the admin
forms, but I think FormUI is a little far off for that right now. Even
if we switched the whole admin system to FormUI when it becomes capable
of this, the podcast plugin (or any plugin) would continue to work if it
used its own template, and the series of hooks would fail, which is why
I think this way is a good way forward.
The theme system already allows plugins to provide additional templates
that can be used for admin pages. We just need to tell the podcast
plugin to do this. The "admintheme" plugin in the extras repo
demonstrates some of this functionality.
All that said, I'm happy to entertain more clever alternatives.
> * filters the RSS output to include the enclosure data for the media,
> as well as inject all the necessary iTunes bits.
This is probably a better solution than the one that was in the RSS
plugin when I last saw it, which adds the enclosure data directly from
the postinfo itself. We'd simply move the code from RSS to the podcast
plugin.
> (If there are other things to do, please let me know -- I'm not a podcaster.)
The RSS output is not currently filtered for autop, so the text all runs
together in the output. Should we apply the same output filtering on
the feed as the site display itself? How do we accomplish that?
Also, apologies in advance for any interchange I make between RSS and
RRS (already did it in the plugin once), where RRS is an abbreviation I
use commonly for the company I work for.
Owen
Michael C. Harris
> I propose that we create a new plugin called "podcast" that does the following:
> * registers a new content type called podcast
> * modifies the post composition screen to include a field in which one
> places the URL to the podcast file they're publishing
How would this work with a silo? Wouldn't the ideal be that a
podcaster had their audio service silo, browsed their podcasts and
double clicked?
I'm not a podcaster either (although maybe I would be if Habari's
implementation was cool enough :) so I might not 'get' the workflow.
--
Michael C. Harris, School of CS&IT, RMIT University
http://twofishcreative.com/michael/blog
Owen Winkler
> On Sat, Mar 08, 2008 at 02:11:19PM -0500, Scott Merrill wrote:
>
>> I propose that we create a new plugin called "podcast" that does the following:
>> * registers a new content type called podcast
>> * modifies the post composition screen to include a field in which one
>> places the URL to the podcast file they're publishing
>
> How would this work with a silo? Wouldn't the ideal be that a
> podcaster had their audio service silo, browsed their podcasts and
> double clicked?
When you double-click an asset, you'd get some kind of interface that
would allow you to set that asset as the one to use in the enclosure.
How to accomplish this (displaying a menu on double-click instead of
just inserting the image, along with how to say "I want to insert this
image as a thumbnail that is linked to the original") is something that
can currently be done, but there isn't any UI for since we've not yet
needed to include it. Hopefully we can include this quickly in the
tweaks to the media browser that are likely to come with Monolith?
Owen
Michael C. Harris
Yes, very clever. If there was an example of that then #217 would be
trivial too.
rick c
rss plugin.
I like the idea of an audio silo from which you select the podcast you
wish to use, especially if it inserts the interface to listen to the
podcast at the current insertion point in the post, whether it's a
link to the podcast or a player if one is included in the plugin.
Regarding formatting the output of the feed, whenever PodPress would
have a bug that stopped feed formatting from happening, it was a major
source of bug reports. People get upset when their feeds don't look
good. :)
Rick
On Mar 8, 5:46 pm, "Michael C. Harris" <michael.twof...@gmail.com>
Khaled Abou Alfa
subject as there are things I think that should be considered in the
implementation and well that can be taken from work already done by
others.
PodPress is far too convoluted and complicated for what it is meant to
do really. It's far too clunky for it's own good.
Having trolled around several places, Ronald's Podcasting plugin
(http://cavemonkey50.com/code/podcasting/) offers an excellent set of
tools that allows you to just get on with the whole thing. Crucially
you get the chance to put all the relevant options in one area. The
options pages has the following items:
1. New dedicated podcast feed. I think this is a great idea, because
it makes it removes the issues that crop up with posts that are not
podcasts to be put within your podcast feed.
2. Title and Podcast tagline.
3. Then you've got your itunes options, summary, author, podcast
artwork, categories, keywords, Explicit or not, Owner name and owner
email address.
4. Then you've got the last field which I think is pretty smart as
well. You can have additional formats/rss feeds to distringuish
different kinds of the same podcast. So in my case I am using an
enhanced version and a simple mp3 version.
When it comes to loading the podcast into the post, this is where we
can move things to the next step, because currently you load the
actual podcast and then copy paste the url into another field. This
can all be one step in our case, upload and insert as per any other
media file, but as a podcast enclosure.
The plugin allows for a player to be embedded within a post if it's an
mp3. Podpress has tried to get a player to deal with the enhanced aac
format but alas I've never seen it in practice done by anyone and i
certainly never got it to work, so I'm think that it's not a
necessity. So in this case a message would appear that would warn the
end user that this format cannot be embedded within a player however
that it can still be uploaded as a podcast within the necessary
enclosures as long as it's linked in the post (or something to that
extent).
Angelo Mandato
First off, I'd like to thank Scott for introducing me to this project.
Every time I look at the code base to learn a little more I get pretty
excited with the direction of Habari.
I want to introduce myself before I start to weigh into this
conversation. My name is Angelo Mandato, I'm a programmer with a
background in PHP. More importantly, I've been developing web
applications for RawVoice (www.rawvoice.com) since the company was
founded in August of 2005.
We've built our own system for managing a network of podcasts, more
inline with how Loudblog (http://www.loudblog.com/) works than how
Podpress works. Loudblog does a few interesting things such as web
media file uploads and writes ID3 tags to mp3s. If you are looking for
examples of blog/podcast platforms to be inspired from, I would
recommend looking at Loudblog. As someone else noted above, Podpress
is a bit bloated and in recent months has become a semi-branded
product, some Podango exclusive features have been added to Podpress.
As far as plugins go, I would separate the enclosure from the podcast/
iTunes logic. enclosures can be in an Atom feed in the form of <link
ref="enclosure" ... (I may have the syntax wrong but the link type
enclosure is the just of it). So what I would recommend is the
enclosure of the media be built into the blog application. It's really
just another custom attribute to a feeds item.
For the podcast plugin would then add the iTunes namespace as well as
elements and attributes to the RSS 2.0 feed. The only objectives the
podcast plugin would need to accomplish is to provide in-page playback
(I recommend FlowPlayer for mp3 and flash video) and you would have
the basics ready to go.
More advanced features would include the ability to manage and upload
media files from within Habari. You could even do what we (RawVoice)
and Loudblog does and use the getid3 library and write id3 tags to the
uploaded mp3s. This functionality would all be bonus but not necessary
to get the job done.
To give you an idea what we're doing at RawVoice, I've just completed
a publishing interface for Podcasters to manage the media podcasters
host with us. The interface makes it easy for podcasters to upload
media (web based uploader with 200MB file limit, uses C++ CGI to get
around the PHP post and time limits) and we're hosting media over a
cluster of servers. Podcasters who have large audiences can't host
their media on one server, that's where services like ours come in.
We're not about to re-invent the blogging platform though, so what
we're doing is utilizing the Blogger/MetaWeblogAPI so we can cross
post to existing blogs. The MetaWeblogAPI allows for the enclosure
value to be sent as a struct to the Metaweblog.editPost/newPost, it
seems no one has implemented this functionality in any of their blogs.
I just wrote the code necessary for Wordpress to handle this
functionality and would like to help Habari add this functionality to
its MetaweblogAPI plugin as well. I also noticed that the MetaWeblog
API plugin for Habari does not handle the mt_keywords value, it would
be nice to see this added as well.
So that's my background, my thoughts and what I'd like to do to help.
My question is, how/when can I get started helping out?
Thanks,
Angelo
Andrew da Silva
I wrote the MetaWeblog plugin, it is complete as per the MetaWeblog
specs. You must be used to see a mixed/custom implementation.
Wordpress uses a mix of Blogger and MetaWeblog, this is a planned
feature, since more desktop editors support it and it has more
features.
You are more than welcome to come in #habari on Freenode if you want
to talk about this plugin, we could implement your code in the current
plugin and do some podcastìng! :)
Andrew
>
> - Show quoted text -
Angelo Mandato
The original specifications for the MetaWeblogAPI posted by Dave Winer clearly explains the enclosure struct option as an example. It is not a mandatory option that the server has to entrupret, but it is invaluable to those who podcast that it does support this. http://www.xmlrpc.com/metaWeblogApi Please refer to the 3rd paragraph under the "The struct" section of this page.
I just added a patch to Wordpress so that it can handle the enclosure in the XMLRPC editPost/newPost functions. http://trac.wordpress.org/ticket/6392
The MetaWeblogAPI, Wordpress API and MovableType APIs that Wordpress uses all extend upon the original Blogger 1.0 API. If you want subcategories from a web log, you have to use the MovableType API functions and if the server you query has subcategories, it returns valid data. If you want to edit pages, you must use the Wordpress API, as they were the first to add XMLRPC functions for that functionality. The key functions though are defined by MetaWeblogAPI but all 4 API's can be used together for a common goal to manage a blog with a web service or application. To me, the main thing that the MetaWeblogAPI did was open the door for any element and attributes found within an RSS 2.0 item to be included in the editPost/newPost content struct.
I'm trying to get Chatzilla installed, once I do I'll join #habari.
Thanks,
Angelo
Andrew da Silva
The only problem I see now is how to manage the episodes, maybe the
Simplefile silo can be used to upload episodes and assigned to posts?
I don't know if, for example, MarsEdit can upload media?
On Mar 26, 1:26 pm, "Angelo Mandato" <amand...@gmail.com> wrote:
> Hey Andrew,
>
> The original specifications for the MetaWeblogAPI posted by Dave Winer
> clearly explains the enclosure struct option as an example. It is not a
> mandatory option that the server has to entrupret, but it is invaluable to
>
> I just added a patch to Wordpress so that it can handle the enclosure in the
> The MetaWeblogAPI, Wordpress API and MovableType APIs that Wordpress uses
> all extend upon the original Blogger 1.0 API. If you want subcategories from
> a web log, you have to use the MovableType API functions and if the server
> you query has subcategories, it returns valid data. If you want to edit
> pages, you must use the Wordpress API, as they were the first to add XMLRPC
> functions for that functionality. The key functions though are defined by
> MetaWeblogAPI but all 4 API's can be used together for a common goal to
> manage a blog with a web service or application. To me, the main thing that
> the MetaWeblogAPI did was open the door for any element and attributes found
> within an RSS 2.0 item to be included in the editPost/newPost content
> struct.
>
> I'm trying to get Chatzilla installed, once I do I'll join #habari.
>
> Thanks,
> Angelo
>
>
> read more »- Hide quoted text -
Andrew da Silva
I won't integrate your patch in the plugin, I feel we need a full
plugin dedicated to Podcasting.
1. We need a feed specific for podcasts, or filter the main feed to
output podcasts.
2. I don't know what to do with the <enclosure> URLs.
3. We could easily use the Audio Player plugin to play Podcasts within
a post.
Therefore, it's not all MetaWeblog-related.
What I'm prepared to do is comment the plugin, and add plugin hooks so
people can extend/add support for specific structs or other.
On Mar 26, 2:44 pm, Andrew da Silva <andrewdasi...@mac.com> wrote:
> Thanks for the links, I'll look into it.
>
> The only problem I see now is how to manage the episodes, maybe the
> Simplefile silo can be used to upload episodes and assigned to posts?
>
> I don't know if, for example, MarsEdit can upload media?
>
> On Mar 26, 1:26 pm, "Angelo Mandato" <amand...@gmail.com> wrote:
>
> > Hey Andrew,
>
> > The original specifications for the MetaWeblogAPI posted by Dave Winer
> > clearly explains the enclosure struct option as an example. It is not a
> > mandatory option that the server has to entrupret, but it is invaluable to
>
> read more »
Angelo Mandato
I don't know the database schema of Habari well enough to know where the enclosure data can be stored. In Wordpress, it goes into the postmeta table, except if Podpress is installed it is stored in the Podpress settings. I don't like the enclosure data stored in Podpress myself because if Podpress is uninstalled, you loose all that data. All the other information for itunes elements in the feed use data that already exists or is set in the Podpress settings. The enclosure's URL, length in bytes and mime type are the crucial pieces of information that a podcaster would hate to loose. I'm thinking out loud here, where and how the data is stored will be determined on Habari's database structure, which I am not familiar with.
I think plugin hooks for the getPost addPost, editPost and deletePost functions would work.
I've been looking at SixApart's list of the API functions (http://www.sixapart.com/developers/xmlrpc/), it would be ideal to be able to add MovableTypeAPI and WordpressAPI XMLRPC plugins if one wanted to add the features they provide. I don't see any value with the MovableTypeAPI functions, but the WordpressAPI functions allow you to manage pages, which would be pretty cool to do with an XMLRPC client. Can additional plugins integrate into Habari's XML-RPC server or is the MetaWeblogAPI plugin the only one that can?
More interestingly, does Habari have any functionality that no API addresses currently? Perhaps a HabariAPI could be added to the set of XMLRPC APIs?
--angelo