Re: Broken i18n and the new UI handler.

[Havoc Pennington <hp redhat com>]

Hi Daniel,

I don't mean that libxml or xmlNode is large and error-prone for an
XML node, I mean it's large and error prone to store some other kind
of data.

For example in the GConf backend I could store stuff internally as:

 struct _GConfThingy 
 {
   gchar *key;
   GConfValue *value;
   gchar *schema_name;
 }; 

or something like that. For efficiency reasons (speed, not memory) I
instead store the xmlNode tree. However, xmlNode is clearly larger than 
struct _GConfThingy above, and also a good deal harder to use. Which
resulted in buggier code than I would have had with a task-specific
data structure.

The reason I store the xmlNode tree is to be able to quickly save at
any time without having to build the tree. I could have avoided saving
the tree with some cost in time it takes GConf to sync to disk.

So, I think you misinterpreted what I was trying to say, I am just
saying that making people use the raw xmlNode instead of a simpler
data structure designed for the task is not a very nice API.

There is also some value in building an abstraction barrier between
the menu API and the exact XML DTD and parser being used, I think.
That gives you a lot more future flexibility.

>  - while we are speaking about size, what is the largest input you
>    envision to use in GMarkup ? Did you made any serious estimate of the
>    memory needed by the equivalent libxml output before writing your
>  own ?

GMarkup wasn't written to be smaller than xmlNode (though it is, just
because it doesn't support many XML features). The point of GMarkup is
mostly to just be in the GLib style and small enough to go in GLib.

I actually think a full XML parser could be small enough (remove some
of the addons such as nanohttp and xpath, etc.) - but I'm not sure
it's worth doing that given that we already have libxml. I don't
personally care to maintain such an alternative XML parser at least.
So since that won't happen GMarkup will have to do.

>  - How do you intent to handle I18N and L14N issues in GMarkup ?
>

GMarkup just loads and saves UTF8, and that's it.
 
> So i understand the reasoning behind GMarkup. But don't associate it
> with XML it's not designed for this. If I had time I would spend the
> 2 hours needed to make a SAX backend generating the same data
> structures as GMarkup.  It would be a good way to learn what are the
> differences and provide a reasonable way to compare both on real
> stuff (and see if a fallback is possible for apps who may grow their
> usage of GMarkup beyon the scope it was designed for).
> 

If you have time to look at GMarkup and help ensure it is a genuine
XML subset, that would be a very good thing. As long as it only saves
valid XML, people can easily upgrade to libxml in the future.

Havoc