Re: [xml] Beta release of 2.6.0beta2

[Daniel Veillard <veillard redhat com>]

On Thu, Sep 25, 2003 at 08:56:39AM -0400, Stefan Seefeld wrote:
> >   Well there is no new feature, yet. The main change is that all errors
> > from the XML parser module are now processed via a few routines at the
> > top of parser.c . Those routine in turn call the existing APIs. However
> > it should be relatively easy now to plug a new error intercerption layer
> > at a "logical" level. The routines get the parser context if available,
> > the xmlParserErrors value and some extra arguments for better error 
> > reporting. Now, I expect interested people to discuss the kind of
> > interfaces they would like, and if made in time I will provide this 
> > in 2.6.0
>
> Great. I guess one thing to do would be to provide a callback 
> registration function that lets users replace the default handler
> (which, as you say, just redirects to the 'old' callback interface)
> with they own, and thus write little tests to get a feeling for the
> new API's use. What do you think ?

  A callback for what and how ? It's the problem. People complain,
they want something better. Okay, give me the signature of the function
you want and I will try to make a callback registration. Now let's the
fun begin:
  - do you want it to be per parser context ? Then how do you report
    error outside any parsing context ?
  - if not related to parsing, then it has to be a global setting.
    Is it per thread ? or not ? Will this introduce an ABI breakage ?

> This could then immediately be tested in a variety of 

  No you didn't defined what you want. I don't know what you (collectively)
want. So don't avoid the discussion and try to get an answer from me, 
I already provide APIs for errors, if people don't like them fine, but
feed me with a real well defined answer !

> Could such a registrator be added to the cvs snapshots so we have some
> time to play with it before the next beta release ?

  if I get a precise definition yes. If you want a callback to set errors
there are already 2 of them, one for global errors, and one for per
parsing errors in the sAX callback. So now do your part of the work,
I'm fine with the current error API state, you (collectively) want something
else, fine, but what ?

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/