[Glade-devel] Why libxml2 and not GMarkupParser?

[johnp martianrock com (John (J5) Palmieri)]

On Sat, 2004-01-10 at 17:10, Tim M�ller wrote:
> On Saturday 10 January 2004 10:58, Olexiy Avramchenko wrote:
>
> > As for size issues: I'm afraid that Glib's markup stuff doesn't handle
> > compressed xml files,
> > like libxml2 does. For example: I have ~600KB xml for my current
> > project, gzipped it's about ~36KB.
>
> That's a good point. I didn't know it was possible to use gzipped XML files 
> with libglade, and it certainly makes sense.
>
> However, in that case I'd just add a dependency to libz (which is already 
> there anyway when using Gtk+), and decompress the file/buffer in libglade 
> using libz before feeding it to the GMarkupParser.

I agree that gzip'ed xml files are not a compelling reason for using
libxml2 however Glade uses a full XML spec and is not just a simple
configuration script reader.  Questions to ask are is Glade going to use
advanced XML functionality in the future?  How about embedding SVG
graphics for icons?  Is moving to GMarkup really gain us anything or is
it just a hunch that since it is not a complicated a lib nor as big this
means instant meaningful gains?  Is startup noticeably any faster with
GMarkup?  Can we perhaps have GMarkup as a compile time option for
embedded uses instead of betting the farm on it?  Is GMarkup going to be
as well maintained as libxml2 is today?

Historically libxml was used because GMarkup had not been implemented
yet and libxml was the standard.  To rip that out now might not give us
all that much benefit.  Comparisons need to be made of each case.  I
personally don't think moving to GMarkup is a good idea just because it
is was setup to be just a configuration reading library.

Here is a blurb from the docs:

The "GMarkup" parser is intended to parse a simple markup format that's
a subset of XML. This is a small, efficient, easy-to-use parser. It
should not be used if you expect to interoperate with other applications
generating full-scale XML. However, it's very useful for application
data files, config files, etc. where you know your application will be
the only one writing the file. Full-scale XML parsers should be able to
parse the subset used by GMarkup, so you can easily migrate to
full-scale XML at a later time if the need arises. 

If size of the libxml2 library is an issue have you tried compiling with
some features turned off?  

This is not to discourage you from porting to GMarkup.  I just think for
such an important piece on the desktop we need to stick to standards
just to give us room to expand in the future.  I guess I would say the
best thing to do is try to integrate GMarkup as a compile time option
where others can go and benchmark the two approaches to see which is
best.

--
J5