Re: XML libs (was Re: gconf backend)
- From: Malcolm Tredinnick <malcolm commsecure com au>
- To: desktop-devel-list gnome org
- Subject: Re: XML libs (was Re: gconf backend)
- Date: Sun, 28 Sep 2003 17:10:37 +1000
On Sun, 2003-09-28 at 16:30, Havoc Pennington wrote:
> On Sun, 2003-09-28 at 01:09, Malcolm Tredinnick wrote:
[...]
> > ...there are applications
> > that do use the full facilities of XML. People working in other areas do
> > require the extra functionality.
>
> Sure, I buy that. But they are apps that are about documents. For my
> core-ish desktop component apps, my priorities are robustness, good
> error messages, size, and other implementation issues; and not having to
> read and understand a big pile of specs. ;-)
The "size" arguments have not addressed applications that don't just run
alone on the desktop (i.e. every single application out there). The
first word of "shared library" is important. :-)
The point I was making, though, was that the other applications are just
as much a part of GNOME and the XML requirements of GNOME and need to be
kept in mind. This thread has expanded to talk about the use of XML in
GNOME applications, so I want to make sure all applications are
considered equally (although I am also amenable to letting the ones I am
interested be treated especially well). The danger of forgetting this is
that we start to use a dumbed-down library and that becomes the GNOME
XML library of choice and then somebody has to look outside the platform
to use libxml2. The fact that GNOME currently ships a compliant, very
functional, fast XML library is very important. (I know you are not
advocating removing it or anything, but mail archives have a way of
living on and being misinterpreted later on.)
> > What this (and some of your other posts in this thread) seem to be
> > saying is that we need an education program here. Application developers
> > need to know which bits they can safely ignore and which bits should
> > result in the application gracefully failing (*not* ignoring -- then
> > we're back in airline checklist territory).
>
> Once people have to read the docs you've already lost on an important
> level. Yes I know people have to read some docs sometime, but any given
> person only reads half the docs they ought to read.
>
> APIs that simply force you to do everything you need to do, by having
> the required information as mandatory arguments and puking if it's not
> provided, or making you provide a callback for everything that matters,
> or whatever, are better than docs.
> The "there's only one way to do it" principle is a big win here as well.
It's a nice principle, but it's often not possible. This is one of those
cases, unless you restrict your problem domain severely.
Beginning to flog a dead horse, but...
That is why what you are asking for can *only* be a convenience wrapper
over the top of the real library, appropriate for a small set of
applications. It is not the real thing. On a pragmatic level (you
writing your code), this is possibly not important to you. In the bigger
arena, when somebody is asking later how to do XML processing, everybody
needs to remember the limitations that come with the benefits of such a
wrapper. That distinction (in many areas of choice, including choosing a
library) is something we really mess up a lot on the GNOME mailing list.
> One worry I have about this whole discussion is that it could lead to
> more API in libxml2, and I'm not sure this is a good idea.
Probably not. Everybody involved so far is aware of the plusses and
minuses. And it's just not a sexy topic like the file manager, so we are
unlikely to have another 47 people posting on Monday.
One thing I will observe is that most of want you are after -- modulo
some of the more specific error handling -- is already available with
libxml2: I originally wrote "easily available", but that is only as
correct as saying it is "easy" to use GTK+ or something similar. I will
agree that it can sometimes be very fiddly to make everything work
together, but the facility is there. I think your idea of a wrapper to
provide the simpler API for the "configuration file"-like case is
possibly the right solution.
Anyway, there's enough to think about here. Time to go back to actually
using libxml2 for stuff (hmm .. possibly I shouldn't contribute to this
thread in between sessions of working with XML). :-)
Cheers,
Malcolm
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]