Development

Posted by Elizabeth Dalton 23 Nov 2005 22:13 GMT-0000 posts: 38 ☆ ☆ ☆

Proposed changes to support media casting:

We'd like to do podcasts from Tiki. Actually, we'd like to support media casts of all kinds. Currently we can take the RSS output from File Galleries and run it through FeedBurner, which converts the feed to something podcast compatible, but that seems silly. Why not update the RSS feed so it has all the information needed to support a podcast directly?

Current Tiki RSS feeds include the following information for each "item": title, link, description (text), author (email), and publication date. Podcasts need a number of pieces of information not included in the current RSS feed, including media type, duration, bit rate, frame rate, etc. This data is not currently captured when files are uploaded to a gallery, for example, but it could be. Manually recording it would be a nuisance, but that shouldn't be necessary.

The solution I propose involves using getid3.php (currently used in the MFolder plugin), which extracts all the required information directly from the file (I THINK — I'm not sure about frame rate). This file currently isn't part of the default installation, and may slow down file processing on upload or something. In the spirit of the 3 Rules, either media casting needs to be an option on the existing file gallery feature, or a separate feature called Media Cast needs to be created. I'm not sure which is preferred from a Tiki development point of view. I suggest the latter, but re-use the existing code as much as possible. Alternatively, the getid3 package could be included in the installation process and all the file_gallery stuff could be updated to support the required number of fields for length and filetype data, etc. That would probably be cleaner, but I'm not familiar enough with the existing code to be sure I've caught all the changes that would have to be made not to break file galleries completely.

Documentation of what needs to be done for full iTunes compatibility is here: http://phobos.apple.com/static/iTunesRSS.html. I also took a look at other existing services, e.g. FeedBurner, to see what they provide in their XML feeds. FeedBurner not only provides the "enclosure" tags required by Apple but also provides "media" tags presumably used by other services. It seems trivial to support both. There are also some iTunes specific tags to be supported both at the channel and item level. The only other bit of effort that would be required is to support the iTunes category lists.

Here's what I think would need to be done (but I'm new to Tiki development and to PHP, for that matter, so I'd like a sanity check on this):

Create the following:
tiki-Mediacasts.php (similar to tiki-file_galleries.php)
tiki-MediaCast_rss.php (similar to tiki-file_gallery_rss.php, subscribes to one MediaCast)
tiki-Mediacasts_rss.php (similar to tiki-file_galleries_rss.php, subscribes to all MediaCasts on this Tiki)
lib/mediacastlib.php (from lib/filegallib.php, but uses getid3 code in the insert_media() function, similar to insert_file() function)
table tiki_MediaCasts (similar to tiki_files, but more fields)

Edit:
lib/tikilib.php
- add the following functions:
get_media() - similar to get_files()
add_MediaCast() - similar to add_file_gallery()
get_MediaCast() - similar to get_file_gallery()
list_MediaCasts() - similar to list_galleries()
list_visible_MediaCasts() - similar to list_visible_file_galleries()

The main difference in all of these is the number of fields used to describe the file, with the extra data being extracted on the initial upload using getid3.

- edit the following functions:
list_sections() - add MediaCasts to the list
get_event_watches() - add MediaCasts to the handling list

Edit:
lib/rsslib.php
Add function:
generate_media_feed - similar to generate_feed, but more XML fields to support the podcast/media cast requirements.

A new table, tiki_MediaCasts, needs to be created. This table has more fields than tiki_files. The setting to decide whether to use the db to store files or not probably ought to be included, but media files are typically so big, use of a directory is much more likely.

Again, the other alternative is to edit the above files and functions rather than creating new ones, and alter the existing tiki_files table. Would that be preferable from a Tiki development point of view? Can someone give me a sense of whether I've found all the places that would need to be changed?

Thanks,

e.dalton