[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#287839: ITP: mxml -- small XML parsing library



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Marcelo E. Magallon" <mmagallo@debian.org> writes:

> On Thu, Dec 30, 2004 at 10:58:08PM +0000, Roger Leigh wrote:
>
>  > >  >     Mini-XML is a small XML parsing library that you can use to
>  > >  >     read XML and XML-like data files in your application without
>  > >  >     requiring large non-standard libraries.  Mini-XML only
>  > >  >     requires an ANSI C compatible compiler (GCC works, as do
>  > >  >     most vendors' ANSI C compilers) and a "make" program.
>  > >
>  > mxml is intended to be minimal, as a counter to libxml2 bloat (and it
>  > *is* a bloated monster).
>  > 
>  > It was deliberately designed to implement *only* the libxml2 tree
>  > interface.  Its first use was in libgimpprint to remove our libxml2
>  > dependency, and provide us with an fast, lightweight, embeddable XML
>  > parser.
>
>  You mean for loading files which look like XML.

I'm not sure what you mean (I'm neither an XML guru nor a fanatic).
The XML files we use are fully conforming XML with a proper schema.
What exactly is the difference between "looking like" and "being" XML?

>  But that's irrelevant.  My point was only that the description that I'm
>  quoting above is neither helpful nor fair.

I think it could perhaps be better worded, described on its own merits
rather than refering to other libraries.  Note however that libxml2 is
not "standard" itself, at least outside of Debian.

>  After reading your post I wonder if "without requiring large
>  non-standard libraries" actually was meant to be read as "without
>  requiring libxml2" (i.e. the "large non-standard library" meant here is
>  libxml2).

Yes, you would be correct.  It was explicitly intended as a drop-in
replacement.  All it required was a few regexes to change the prefix
on the function and datatype names.

>  > I would suggest to the OP that you provide a static version, since
>  > many of us do use it linked statically.
>
>  That's so sweet... first you complain about libxml2 being large (which
>  is true, having an HTTP client and all that embedded in it) and then
>  you go on and say that you embed the little one statically in other
>  components.  Just for kicks:
>
>  $ find /usr/bin -type f -print0 | xargs -0 -n1 readelf -d 2> /dev/null |
>    grep NEEDED | grep libxml2.so | wc -l
>  145
>
>  So that's 145 binaries which might end up sharing 1 MB worth of pages
>  on the system.  Imagine all those embedding mini-XML ... 145*12 :-)

I'm not suggesting in any way that embedding is a good idea.  For us,
it was mainly a question of portability to other systems (e.g. MacOS
X) which don't come with libxml2.  So it was mainly an issue for
packaging and distribution.  The size issue was there, as was the fact
that we only used a tiny fraction of the API, but being self-contained
was more important.


Regards,
Roger

- -- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFB1WttVcFcaSW/uEgRAleFAJ0Uvvo3ZcDk/gHTZ85NIHaikLdFywCggTp6
uAeZ29wlFSiOEG+c4o6+QC4=
=1t3D
-----END PGP SIGNATURE-----



Reply to: