[MTOS-dev] XML parsing

[David Jacobs]

I imagine that the future of MT is more and more distributed, and that
means that making XML work effortlessly and everywhere should be a top
priority. So now is the time to fix this - thanks, Mark!

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.

David


On 3/5/08, Mark Paschal <mark at sixapart.com> wrote:
> Hi, mtos-dev folks,
>
>  I told Tim a while ago I would start a thread about XML parsing in MT,
>  so I'll take the current quietude as an opportunity to do so.
>
>  While we don't parse XML in any of the core functions, we do in:
>
>  * the Atompub server(s)
>  * profile exchange for OpenID commenters
>
>  Given our general product requirements and that the larger Perl
>  community applies TMTOWTDI doubly to XML, parsing XML presents some
>  challenges. XML::Atom, the CPAN module we use in our Atompub
>  endpoints, will use the preferred XML::LibXML if available, but we
>  ship XML::XPath in extlib to have known minimal XML support.
>
>  However, XML::XPath uses XML::Parser, which requires the expat library
>  for the heavy lifting. While most servers have expat (removing it on
>  my dev machine through the package manager would remove 185 dependent
>  packages--essentially everything), it is a dependency, and completely
>  fresh servers using some UNIX distributions may not have expat
>  installed. When neither libxml nor expat are installed, it's not
>  obvious what the problem is; mt-wizard reports that XML::Atom is
>  missing, which isn't precisely the case.
>
>  It would seem we could further use the same fallback technique we
>  already use, eventually falling back to a pure-perl XML module such as
>  XML::SAX::PurePerl. To keep developing MT and plugins simple, though,
>  we would want to build a sort of "XML::Any" module that encapsulates
>  the selection of an XML library and provides a common API. That's a
>  non-trivial undertaking, so other solutions are welcome.
>
>  Does anyone have other thoughts, problems, or solutions about XML
>  parsing in MT?
>
>  This isn't a pressing issue and isn't a performance focus, but I see
>  us doing much more in the future with Atompub and XML APIs (I
>  certainly am in my hack-day time), so we should plan for it. Thanks in
>  advance for your input!
>
>
>
>  Mark Paschal
>  Software developer, Movable Type
>  mark at sixapart.com
>  _______________________________________________
>  MTOS-dev mailing list
>  MTOS-dev at sixapart.com
>  http://www.sixapart.com/mailman/listinfo/mtos-dev
>


-- 
David Jacobs
http://Apperceptive.com
917 450 0533