Re: GSXML

[Richard Frith-Macdonald]

Nicola Pero wrote:

> > > > Reports of all such inconsistencies welcome ... the classes were 
> > > > originally written
> > > > by someone unfamiliar with OpenStep, and while Nicola and I have put 
> > > > some effort
> > > > into making them more consistent, the job is not complete.
> > > Since you quote me, I need to correct you - as I already said in public
> > > posts, I think it's not just a problem of consistency or of details ...
> > > the GSXML classes and their API are basically flawed and should be totally
> > > rewritten.
> > I think that's a bit misleading taken out of the context of the earlier 
> > discussion.
> >
> > The basic flaw in the GSXML classes is that they are based on libxml, and suffer
> > the memory management problems of libxml.  This basically manifests if you want 
> > to
> > use them to create XML, not for parsing.
>
> The only thing which works properly is the SAX parser.  Everything else
> (if used seriously) will leak memory, or crash.  Since the original
> question was about something which is not the SAX parser, that seemed an
> appropriate comment to make.
>
>
> > The 'quick' fix is to change  the GSXML API to better reflect the limitations 
> > of the underlying libxml model, 
>
> This 'quick' fix would involve rewriting the API nearly from scratch, and
> would break completely any program using GSXML for anything but SAX
> parsing - so if you are planning on such a 'quick' fix it's just fair that
> you tell people who are asking queries about the API.

I have to say that in that case I don't know what on earth you are 
talking about.

You say that everything else 'if used seriously' will leak or crash. 
Yet I've been using it 'seriously'
for ages without any such problem.

While it's quite possible that there are minor leaks (easily fixed), the 
code will certainly not crash
*when used as a parser* unless you release the document you are parsing, 
and the API changes to
prevent the memory management problems it has as a parser will not have 
impact on the parsing
API ... they only impact the document editing API.

The code only has problems if you mess about with memory management  - 
and you almost
never want to do that unless editing documents (something the API was 
not supposed to do ... the
methods which look like they were supposed to do that were basically  
supposed to be for inernal/expert
use).

So, the code is quick and reliable when used for the purpose being 
discussed AFAIK.
I think you are commenting from the point of view of someone who wants a 
general XML manipulation
library  rather than an XML parsing library.  While I'd like such a 
thing eventually, it's not what GSXML
claims to be.