Re: [PEPr] XML::XML_Feed_Writer deleted

I haven't looked at any code yet, but I can already tell there are some issues that need addressing: 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. 2) There appears to be a no-man's land in PEAR for XML support. We have PHP 5's excellent DOM. We have PEAR XML packages prominently saying to use the PHP 5 XML functions in place of the PEAR packages. Despite the fact that PHP 5 has been out for a while, PHP 4 code is still predominant, even in PEAR packages. Personally, I refuse to write PHP 4 classes unless forced. If I were writing just any PEAR package, it would be in PHP 5. Since this package involves XML, PHP 5's DOM seals the deal. In my opinion, PHP 4 for all intents and purposes is deprecated for new development. If I were in charge of PEAR, I would say that all new packages that don't extend any existing packages need to be written in PHP 5, but that is just me ;) Just some food for discussion, Gregory Szorc gregory.szorc@case.edu Dan Rossi wrote:

Well , the only thing i am going to meantion, you extend or compose the PEAR.php which is in php4 style coding right , so i dont get it, ive been running php5 since the first betas and yes it does handle xml better there is no question about it, however to back your argument I would either not compose or extend php4 classes, not that its danegrous ??, create a port for php4 aswell or not code in php5 yet :) What i would suggest for most of the xml packages is to have an option to use the native extenions if compiled, i dont know if it already does that ? Alot are built so there is no need for extensions, so is all handled in php, so prob a little slower, ig uess they would then become wrappers upon wrapper functions and disprove their worthiness then ? On 09/02/2006, at 12:56 AM, David Coallier wrote:

Dan Rossi wrote:

I think this package would be extremely useful. It should however maybe use the pear xml packages somewhere to handle stuff. It should maybe have factory methods for different feed types like RSS, Atom, XSPF for instance (sorry havent looked completely). It is in PHP5 though so it makes me wonder should there be different channels created for a php4 port and php5 port ?

I will not be coding any php4 port that will be handling XML, if someone feels like doing XML_Feed_Writer_P4 or something that's their choice, but with the XML processing ability of php4, I refuse to do so because first of all, I want to port most packages to php5 only as php4 is in my opinion deprecated by it's lack of OO, lack of security, lack of complex XML structures handling (libxml2), lack of Exceptions, SPLs, xslt, thus I believe that all the future packages, if want to please the market and at the same time be reliable, should be php5. Hrmm what else ? I have static:: binding patch installed and namespaces running on my dev version of php5 and I have to admit that it works pretty well.

IE is there going to be a complete PHP5 pear repository port and an equivalent where possible PHP4 port ? I think its silly to write PHP5 pear classes extending or composing PHP4 classes dont you think ? I would just keep them PHP4 for now until there is possible channels available.

And again, I have to disagree, there is php5 packages already, and the php5 port, php4 port will probably take a little while to develop or get in production, so no, I will not do any xml documents handling with php4 unless someone has an idea, or the idea of using xmlwriter efficiently, but again, I would need some benchmark on both sides and the exact same abilities that the script has right now. Because the package does work pretty well, just the architecture is bad, very bad. Although I am very opened to any design if anyone has anything to propose. The main problem right now are the files, atom0.3.php, atom1.0.php, rss2.0.php,etc. They work, but how do you people want them to work ? I started redisigning it about 2 months ago, but it's at home, I'll check tonight and let you guys know of how I started the rewrite(because I can't remember at all), just let me know if you have an idea in the meantime. --David