incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject Re: Consistent implementation of the whitelist
Date Wed, 01 Feb 2012 14:21:07 GMT
On Tue, Jan 31, 2012 at 15:42, Andrew Lunny <> wrote:

> * @pmuellr: there is no good pure JS XML parser in Node; there are bindings
> to libxml2, but we can't reasonably expect end-users to have the external
> dependencies for that. I have been using -
> - but it lacks some features -
> notably support for namespaces and the concept of a document (which affects
> absolute XPath selectors)

I could care less about XPath, but support for namespaces is presumably
required to be able to successfully parse android XML files, right?  I
assume there will be a need to do that, in the tooling, somewhere.

The reason I asked about XML parsers for node, if it wasn't obvious, is
that I'd like to see the tooling implemented on node (and CoffeeScript :-).
  But I'm not married to it.  Python would be my next choice - it's widely
available on all of the desktop platforms we would support the tooling on.
 WebKit has traditionally done all their tooling in Perl, but over the last
few years, mainly due to the Googlites, the tooling is migrating to Python.
 The only issue that comes up is having to support old versions of Python
for ancient versions of Mac OS X.

Another alternative would be to write most of the tooling in node, and do
the XML parsing with a single Python script, whose sole purpose in life
would be to read XML and spit out a stream of DOM nodes (or something).
 Eventually there's got to be an XML parser for node, right?  RIGHT?

Another conclusion re: node not supporting XML might be: we shouldn't be
using XML for our configuration files.  JSON isn't a great alternative,
since it's neither human readable or writable.  Or maybe something like
this json tool helps [1].  CoffeeScript Object Notation [2] would probably
be workable.  YAML maybe.


Patrick Mueller

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message