[MTOS-dev] XML parsing

[Timothy Appnel]

I needless have a lot to say on this topic and was in the process of
writing mine up but since DJ touched on one point (kind of) I'll
answer it here.

On 3/5/08, David Jacobs <djacobs at apperceptive.com> wrote:

>  Besides cheerleading (my finest skill), I don't have a lot of
>  immediate feedback, but I want to address the Expat issue. If Expat
>  was a requirement, or even a "strong recommendation,"  it would render
>  a lot of these points moot. As it is now, we are often faced with IT
>  departments who don't want to install anything above and beyond what
>  is required. They see something (be it an OPML tool, or XML::Atom)
>  that doesn't work seamlessly (or is slow) *without* Expat as a bug.

Just say expat is required is not enough. The problem is that
XML::Parser needs the expat source code so it can bind to it when that
module is being compiled. There is SAX driver that uses just the expat
library and doesn't require the source code. It's a bit slower, but
it means XML::Path and therefore XML::Atom isn't an option to MT. (By
the way: what is XML-RPC ala SOAPLite using? Mark P didn't mention
that or Feeds.App Lite in his list of MT XML uses. The former is SAX
along with a simplistic object model of my own making.)

Requiring XML::SAX and having everything work through that
(XML::Simple works through XML::SAX by default) than you are heading
in the right direction. Adding a section like database drivers where
one of the 4 or so SAX drivers in CPAN are checked and a flag of some
type goes up if at least one is not present would mostly address the
speed issue.

Another point here is that mt-check doesn't go far enough. Checking
that a module loads is not enough as this situation shows. What we
call mt-check today needs to be more of a lightweight 'make test' that
can be extended to include plugin/addon tests also.

<tim/>

-- 
Timothy Appnel
Appnel Solutions
http://appnel.com/