Re: [xml] release of libxml2-2.6.0beta3

On Tue, Sep 30, 2003 at 09:22:45AM +1000, Malcolm Tredinnick wrote:
OK, I had a chance to do some playing around with the 2.6-beta stuff
(well, really with CVS). A few comments below, but nothing serious.

  okay, thanks !

Possibly just because of the type of applications I am using with
libxml, I do not have much in the way of real difficulties with the
existing API. Other people have posted their thoughts, which are outside
my experience set, so I have no opinion.

  Well I dislike the lack of orthogonality and control of the set of 
old APIs like xmlSAXParseMemoryWithData() xmlSAXParseFileWithData(),
  I keep them of course but I want something I can explain in a few
pages to newbies starting with libxml2.

My only request, if it's not too much much trouble, is in the SAX error
callbacks. Currently, we can extract the filename, position in the file,
the error number, and the node we are currently parsing without any
problem. However, in the case of something like a mismatched closing
tag, I cannot see any straightforward way to work out what the parser
actually saw. I know what it is expecting and I can sort of reverse
engineer what it saw by backing up in the input stream a little bit, but
that feels very awkward. Alternatively, I can hope the format of the
error message does not change and hunt through the varargs passed into
the error callback, but again, hardly a robust programming practice. :-)

  I could store more error related data in the parser context somehow
like the Gerror block, i.e. errNo, the string, where this came from
(validation, parsing, I/O, memory, namespace, ...), and some extra
informations, see the few error routines in the beta3 version of parser.c
(near the top).

A possible solution: In parser.c:xmlEndTag1(), the information is
available (the 'name' variable that is filled in on line 7018), but it
is only put into the error string and not available on it's own. Is
there any way to pass a piece of auxilliary data around (like a pointer
to 'name' here)? I must admit that I cannot quite see how without
breaking ABI compatibility, but I am possibly not too clever, so it may
be possible.

  Passing it through the parser context when in a parser framework,
or through a global variable (struct) also per-thread when no parser
context is available. Trying to chase down the case where an error
may get raised from the parser while no context is available sounds an
unpleasant but probably useful task <grin/>.

I tried the new library against a few little programs I have lying
around as well as against my libsmil and there were no problems.

  Good, so far I didn't got any ABI compat problem I didn't fixed,
except one but it's under control :-)

So, in short, I cannot see anything in the new code that is going to
cause me nightmares for my limited applications. That is somewhat
impressive given all the changes you have made under the covers. Nice
job. :-)

  thanks !
  So when are you gonna push this SMIL code out ;-) ?


Daniel Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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