From: Emery Coxe Date: 2011-10-14T00:54:57+09:00 Subject: [ruby-core:40141] Should the XMLRPC library support the Nokogiri parser? --0015175df39ab18deb04af3012ae Content-Type: text/plain; charset=ISO-8859-1 Hello all, I pose the question in the title because I have found through working with the XMLRPC class that the options for XML stream parsing are suboptimal. I have seen REXML hang on arbitrarily large streams - an edge case, perhaps, but poor functionality nonetheless. The XMLStreamParser can succeed where REXML fails, but it suffers from the fact that it is one of the older XML parsers and depends on the Expat library, which seems to have been stagnant since 2004. This indicates to me that the XMLRPC could use an up-to-date solution to the problem of XML stream parsing. Since Nokogiri seems to be the direction the language is headed in (it is modern, actively maintained, has a vibrant community and is used widely, etc. etc...), I figured that perhaps the XMLRPC class could use a binding to Nokogiri. Further, I wonder if this binding should make its way into core. I have already made an initial rendition of the proposed changes, and verified that it works for **my** use cases. Clearly, that statement indicates that my changes have not received due scrutiny - both in the form of formal code review from developers far more experienced/knowledgeable than myself, as well as by process of legitimate testing and verification that the introduction of the parser causes no unwarranted side-effects (aside from the dependencies native to Nokogiri). Here is a link to my github account, where my port of Nokogiri to XMLRPC resides: https://github.com/wokkaflokka/xmlrpc-nokogiri Any feedback or input would be greatly appreciated. Cheers, Emery Coxe -- *Emery S. Coxe* QA Intern | Acquia emery.coxe@acquia.com | (c) 281.352.6418 http://www.acquia.com http://www.drupalgardens.com --0015175df39ab18deb04af3012ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello all,

I pose the question in the title because I ha= ve found through working with the XMLRPC class that the options for XML str= eam parsing are suboptimal.

I have seen REXML hang= on arbitrarily large streams - an edge case, perhaps, but poor functionali= ty nonetheless. The XMLStreamParser can succeed where REXML fails, but it s= uffers from the fact that it is one of the older XML parsers and depends on= the Expat library, which seems to have been stagnant since 2004.=A0

This indicates to me that the XMLRPC could use an up-to= -date solution to the problem of XML stream parsing. Since Nokogiri seems t= o be the direction the language is headed in (it is modern, actively mainta= ined, has a vibrant community and is used widely, etc. etc...), I figured t= hat perhaps the XMLRPC class could use a binding to Nokogiri.

Further, I wonder if this binding should make its way i= nto core. I have already made an initial rendition of the proposed changes,= and verified that it works for **my** use cases. Clearly, that statement i= ndicates that my changes have not received due scrutiny - both in the form = of formal code review from developers far more experienced/knowledgeable th= an myself, as well as by process of legitimate testing and verification tha= t the introduction of the parser causes no unwarranted side-effects (aside = from the dependencies native to Nokogiri).

Here is a link to my github account, where my port of N= okogiri to XMLRPC resides:=A0https://github.com/wokkaflokka/xmlrpc-nokogiri

Any feedback or input would be greatly appreciated.

Cheers,

Emery Coxe

Em= ery S. Coxe

QA Intern | Acquia

emery.coxe@acquia.com=A0| (c) 281.352.6418

http://www.acqui= a.com

http://www.drupalgardens.com

--0015175df39ab18deb04af3012ae--