Hi Vincent, Good to see that blog post was useful ;).
In the new component I decided to more or less ignore the older interface in favour of creating a new unified API. The result is that we're currently running highly specific XPath queries against the original DOMDocument. It means more code of course, but it also eliminates some failings of the original approach and takes account of all the possible alternatives from the RSS namespace extensions (like Dublin Core, Slash, and Atom 1.0 - Atom is used as an RSS extension ;)). Feel free to follow along, I keep my repository at http://svn.astrumfutura.org/zendframework/trunk Your own approach works really well too, let there be no doubt, but I'll be broadening the possible range of data to look for which is where a lot of the API uncertainty currently sets in. Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com OpenID Europe Foundation Member-Subscriber ----- Original Message ---- From: Vincent <[EMAIL PROTECTED]> To: Pádraic Brady <[EMAIL PROTECTED]> Cc: Zend Framework General <[email protected]>; Zend Framework Webservices <[EMAIL PROTECTED]> Sent: Saturday, August 2, 2008 9:04:06 PM Subject: Re: [fw-general] Proposal suggested for a Zend_Feed_Reader On Wed, Jul 30, 2008 at 7:08 PM, Pádraic Brady <[EMAIL PROTECTED]> wrote: Hi all, Being the ZF junkie that I am, I have been considering creating a proposal to address a few issues with Zend_Feed. Rather than let loose with the Proposal right away I figured I'd open the floor here (and on #zfdev where, for once :p, I am logged in at the moment), see what the community reception is, and steal...eh...borrow ideas where they make sense. I'm currently towards the end of a second build of a simplified blog aggregation library based on Zend_Feed. Having done this twice I figured it was time to come up with a final solution so there's no third time ;). In using Zend_Feed I've come to realise that it is largely an abstract API to PHP DOM. It imports, parses and presents a more natural API (akin to SimpleXML in a sense) for RSS and Atom feeds. However, Zend_Feed itself does not understand RSS or Atom - understanding these formats and their many versions is left entirely to the end programmer with a few exceptions. Zend_Feed_Reader's primary goal would be to take up the task of understanding and interpreting RSS and Atom. This is a short email (from me, that means it's <3000 words ;)) throwing around some concepts for debate. Current Potential Issues with Zend_Feed Attempting to aggregate multiple feeds using different RSS and Atom standards requires a lot of extra work to correctly narrow all the available data down to common preferred points like: date, id, author, title, content, etc. It also means a lot of edge cases (malformed XML, non-standard RSS/Atom, etc.) also may need to be tracked by users. One of the few interpretive measures is being able to access RSS "content:encoded" data using a content() method. I also note "dc" namespaces are likewise resolved without the namespace prefix. Neither is consistent (e.g. content:encoded is accessible using the namespace prefix as the method name). The second issue is that Zend_Feed is only minimally aware of HTTP. When given a URL it fetches that URL using Zend_Http_Client. Responses are neither cached nor conditionally fetched meaning that once again users must handle these scenarios by themselves or risk wasting precious memory, CPU cycles and bandwidth processing unchanged feeds. Not a biggie since it's easily implemented, but I've seen few Zend_Feed based apps doing it which is really poor practice in the wild. A third potential problem is the assumption that all feeds will follow identical namespace patterns based on the namespace prefix (an arbitrary string). There are two examples here. One is that some namespaces are resolved automatically by Zend_Feed while others are left unresolved which presents an inconsistent API. For example, an RSS 2.0 <entry> element might hold <dc:creator> and <slash:comments> elements with the <dc:creator> accessed as "$entry->creator()" (the dc namespace is automatically resolved by assumption) but the other only as "$entry->{'slash:comments'}" (the slash namespace is not resolved). This can become pretty confusing and require a lot of trial and error programming. Why doesn't "$entry->{'dc:creator'}" also return a typed result like "$entry->{'slash:comments'}? The second is that namespaces are looked up based on the namespace prefix and not the namespace URI itself. Namespace prefixes may be standardised to a vast extent, but there's nothing illegal about using something different. If someone defined an alternate namespace prefix for "slash", existing source code based on using "$entry->{'slash:comments'}" would break. It's a much lesser point but some preemptive namespace registering would help here - there are only so many common extension out there. Resolving Issues? My own resolution ended up being an overhaul of how I used Zend_Feed. By adding a new interpretive layer it's possible to create an additional abstract API which both understands RSS and Atom versions, can present commonly requested data (prioritising similar elements) through a single set of accessor methods, and is invulnerable to namespace changes. It also makes internalising conditional fetches and caching simpler and standardised (whether there are meritable features is arguable but I think so). Originally I had considered building on top of Zend_Feed, but I've, to some extent, ended moving towards a parallel path where the base source is the DOMDocument Zend_Feed creates (allowing direct access to XPath and dynamic namespace registration) while maintaining access to Zend_Feed's other methods by proxy. The point of the new proposal isn't to so much supercede Zend_Feed as extend it's API and capabilities to reduce the level of custom programming Zend_Feed needs to be surrounded with before it's useful in batch processing of RSS/Atom feeds where knowledge of any one specific feed is highly unlikely. I namespace it as Zend_Feed_Reader since it a separate class family not inheriting from Zend_Feed - rather it accepts Zend_Feed_Abstract instances through composition. Your thoughts are welcome. Even if you write a longer email than me ;). I wrote a few classes to get around this myself using your blog posts from before. Since I don't know that much of XML and RSS I didn't share it but it might be of interest, you can browse the source tree of Vogel_Feed_Unified at [1] and Vogel_Feed_Entry_Unified at [2]. It kind of deals with accessing both RSS and Atom feeds through a standardized interface. I'd much prefer a native solution by someone who doesn't suck ;-) [1] http://gitorious.org/projects/vogel/repos/mainline/trees/master/project/library/Vogel/Feed [2] http://gitorious.org/projects/vogel/repos/mainline/trees/master/project/library/Vogel/Feed/Entry Best regards, Paddy Cheers, -- Vincent
