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