Re: [PEPr] XML::XML_Feed_Writer deleted

On Feb 8, 2006, at 11:24 PM, Gregory Szorc wrote:

1) Feed reading and feed writing are joined at the hip. We already have XML::Feed Parser and have proposed XML::Feed Writer. There needs to be a common ground for these two packages. Either a) packages are merged into XML::Feed or b) packages share a 3rd package, XML::Feed Item, which describes an individual entry in a syndicated feed. XML::Feed Parser already contains this class in XML_Feed_Parser_Type and all derived classes. Should XML::Feed Writer be built upon these classes? Should these classes be split into a new project? Should XML::Feed Writer and Feed Reader merge and become XML::Feed? I'm worried that if XML::Feed Writer is built on top of XML::Feed Reader's classes, the reader could change and break the writer, especially in Feed Reader's beta stage. If we separate out the feed entry classes, we buy some insurance for compatibility.

There was some discussion of connections between feed writing and reading some months ago and it seemed to be resolved before I proposed XML_Feed_Parser. My opinion is that these two actions definitely aren't "joined at the hip". Generating basic feeds is a pretty simple undertaking, particularly for anyone using a templating system. Parsing feeds means dealing with other peoples' data and so needs to be more flexible and to take a quite different approach. While we could get around it with careful use of lazy loading, adding a writer would add some weight to the parser and be a disadvantage to those of us who only want to parse feeds. That said, there is definitely some merit in ensuring that XML_Feed_Parser and any future XML_Feed_Writer can interact, particularly as ideas like using atom for data storage take more ground and there become more needs to be able to splice together feed data. I exchanged some emails with David the last time the proposal was updated and talked about that a bit. If both packages are PHP5 only it should be trivial to allow the exchange of DOM Nodes between the two packages so that data from one can be used in the other. I would guess that the use case of data from the parser being handed to the writer would be more common, but am happy to work on ways to implement the alternative too. What's not so clear to me is how we would approach it should XML_Feed_Writer be a PHP4 and 5 package, and I would be very reluctant to undertake the huge refactoring needed to make XML_Feed_Parser work under PHP4. My main concern with the XML_Feed_Writer proposals was partly down to coding style and the fact that some of it was contained in flat files. But more than that it was that it didn't demonstrate much of a grasp of the various specifications and certainly couldn't make use of the full range of options in Atom. It would be a great shame to let a feed writer package into PEAR that couldn't exploit all of the options in Atom. James.