http://cogdogblog.com/2010/07/05/adopt-my-code-please/

Looking around I see being sponsored by AOE Media puts me in good company as they sponsor a number of interesting projects, including my favorite wiki software Doku

I’m hoping this will allow me to actually spend a little time with Magpie, maybe finally find the time to re-vamp the website into something a little more functional.

And last if you’re someone interested in sponsorship work as a whole on Magpie, or specific feature development get in touch.

Thanks again AOE Media.

http://tbrown.org/noted/blogging-with-magnolia

Twitter, Magpie, Chris, Kadavy, SMITHMag. Nice.

Alpha

Alpha means its broken, there are missing features (many of which are actually in the current Magpie 0.7x releases), and stuff will change. Whether you find that exciting or off-putting is a personal thing.

Getting Started

So um, yeah, as of yet no documentation. That said I’ve included the classic magpie_simple.php script, unchanged except for the require statement. For really simple scripts that is all that is required.

Grab the current code, Magpie 2.0-alpha-PR1. This isn’t its final home, but I am taking this opportunity to finally break free of Sourceforge which has been a long standing goal.

(I know, we all prefer a good var_dump() plus source reading to docs, but their current non-existence won’t continue)

Goals for 2.0

There were three over-arching design goals in this rewrite, plus a slew of secondary goals.

1. Support new namespaces and elements, easily

Rather then go on trying to push the universal rules for mapping unknown elements to datastructures (the Magpie 1.0 approach) I’ve focused on making it simple to register custom parsing logic, and having intelligent defaults. (aka more like what Feedparser.py does) I expect that we’ll handle most known namespaces in short order, and barring another total upheaval of the landscape ala the Pie/Atom project should sit us in good stead as feed use continues to become more sophisticated.

2. Pluggable components

You should be able to easily swap out the caching layer (database caches anyone?), the HTTP layer (multiplexed curl?), even the parser. Besides the added flexibility, the theory is this will make embedding simpler.

Who knows, maybe someone will even contribute a pluggable parser that can handle something other then well formed XML.

3. Mostly backwards compatible

For simple stuff, you’re scripts should go on working. There is still a 1 function interface (if you liked that), still bust everything down into a couple of nested arrays for easy looping and echoing. Even where different it should feel familiar.

Known Issues

• Parser doesn’t support xml:base nor xml:lang nor Atom inheritance. It will, but these features still annoy me, and as long as no one is using the code I can’t seem to motivate to support them.

• I’m also not doing all the normalization between feed types that I do in “Magpie classic”. Again, its coming.

• Not sanitizing content yet.

• Not just a new parser, but a new HTTP client as well. Basic HTTP auth support is there, digest isn’t. Haven’t added back in SSL support yet.

• No documentation per se.

Incompatibilities and Gotcha

• Just use $item['content'] instead of $item['content']['encoded'] or $item['atom_content'].

• If caching is turned on, and Magpie can’t write to it’s cache, it will throw a fatal error, rather then quietly working in a degraded state. This might change, but its been a major support issue.

More features

• fetch_rss() now supports taking per feeds options. This was the most requested feature, ever. (e.g. cache age, output encoding, user-agent, etc)

• Parses enclosures, this was the second most requested feature.

• Handles repeated elements properly. (dc:subject, link, whatnot)

  echo $item['dc']['subject'];
  foreach ($item['dc']['subjects'] as $subj) { ... }

• Atom 1.0 support modulo known issues.

• Tests. Most of them based on Mark’s FP tests. More added all the time. Currently not distributing with Magpie as I haven’t really figured out the license issues.

• Confusing new licensing. Stated goal is to license under a dual GPL/BSD license. That means you get to choose if you’re using the software under the GPL, or the BSD. In addition you can upgrade your license to GPL from BSD (as you can with any BSD licensed software) merely by wishing it to be so.

• Lots more, really.

Other then that, its just like Magpie

http://wampad.com/digg/

http://blog.no-panic.at/2006/09/20/flickrss-wordpress-plugin/

http://www.myspacefeed.com/

http://rasterweb.net/raster/2006/02/07/magpierss-rss-for-jsp/

http://cogdogblog.com/2006/01/21/three-rules-of-rss-publishing/

http://www.tokash.org/gregarius/gregariusScreencast.htm

Phil kicked off a new round of testing for Atom 1.0, the results of which are now captured in the Atom wiki. (not to mention a few gentle nudges on Magpie’s lack of 1.0 compliance.)

All of which got me thinking, it would be exceptionally cool if someone made the FeedParser’s tests available on the Atom wiki using Ward’s FIT concept in a documented, reportable fashion.

Any takers?

http://www.feedblog.org/2005/12/xmlbase_was_a_b.html

http://www.wynia.org/wordpress/2005/11/25/opml-sampling-build-a-page-showing-the-best-item-from-each-rss-feed/

http://peeved.org/opensource/RPM/magpierss/

http://www.feedexa.com/

http://sourceforge.net/projects/sux0r/

http://laughingmeme.org/feed/magpierss.rdf

• uniform access to attributes
• support for repeating elements
• Atom 1.0 support

I’ve struggled for forever to figure out how to provide simple, uniform access to the increasingly rich data that people are syndicating (finally!). Eventually I gave up, and decided that the only solution was to rewrite the parser and make it simple to add per field custom logic. (kind of like the enclosure patch adds custom logic). I never got past the initial sketches.

So I’m thrilled that RadGeek has come up with a syntax (and code!) to extend rss_parser.inc to add support, while staying transparently backwards compatible. I’ve got out a dev build for people to play with, and written up some of the new features.

Access Repeating Elements

Lets assume we have a basic RSS item, with several dc:subjects:

<item>
<title>Some Exciting Title</title>
<dc:subject>exciting</dc:subject>
<dc:subject>example</dc:subject>
<dc:subject>whoohoo</dc:subject>
</item>

echo $item['title'] 
=> "Some Exciting Title"

echo $item['dc']['subject']
=> "exciting"

So far, so normal. Now we get special.

echo $item['dc']['subject#2']
=> "example"

echo $item['dc']['subject#3']
=> "whoohoo"

So how many dc:subjects do we have?

echo $item['dc']['subject#']
=> 3

And this isn’t just for dc:subject, it works with whatever elements you like to repeat. (though we’ll need to decide what to do with the Atom link reltype munging hack, I’ll touch on that in a future post)

Access Attributes

Lets assume, we now have an Atom item with a category like:

<category term='atom' scheme='http://del.cio.us/tags' label='Atom' />

echo $item['category@term']
=> "atom"

echo $item['category@scheme']
=> "http://del.cio.us/tags"

echo $item['category@label']
=> "Atom"

echo $item['category@']
=> "term,scheme,label"   // that might want to change to an array

And if we had a second category for that item?

<category term='calendar' />

echo $item['category#2@term']
=> 'calendar'

or maybe an RSS 2.0 guid element

<guid isPermaLink="true">http://inessential.com/2002/09/01.php#a2</guid>

echo $item['guid']
=> "http://inessential.com/2002/09/01.php#a2"

echo $item['guid@ispermalink']
=> "true"

Where from here

So give the dev build a spin, kick the tires etc. This is the largest new feature in a while, and would be good to give it a workout. (ps. I’ve affair the normalization methods are throwing notices currently.)

Also any show stoppers people might see with this new syntax.

Once we’ve got this working smoothly, there are several other new features looking for inclusion in next release.

And finally I’m debating whether to break backward compatibility with how we currently do Atom link munging, in order to get more consistency with this new syntax, and I’d like to get some feedback on that.

In particular this advisory applies to you if you accept unflitered URLs from strangers for passing to Magpie, and you have curl+SSL support compiled into Magpie.