Re: [xml] Which interfaces should be put into LSB?

[Daniel Veillard <veillard redhat com>]

On Wed, Nov 30, 2005 at 03:15:19PM -0800, Banginwar, Rajesh wrote:
> Hi Daniel,
>       Little background first. When we develop LSB specification, we
> try to divide specification for a given library into multiple sections,
> each one representing part of library functionality. The same sections
> then map to corresponding header supplied by LSB build environment. 
>
> In case of libxml2, we were trying to do that based on the headers, each
> one representing the functionality chunk. But while analyzing the
> headers we are coming across multiple include loops. E.g. Tree.h is
> included in parser.h and parser.h gets included in tree.h through some
> include chain (xmlmemory, globals, sax2, parser.h).
>
> How do you suggest we untangle this so that the specification will look
> better organized? One option will be to create aggregated includes,
> reducing the no. of total include files. 

  Each header has a relatively clear purpose, it is written in the 
top comment and used to label the docs descriptions, e.g. tree.h
is 
   http://xmlsoft.org/html/libxml-lib.html
      tree: interfaces for tree manipulation
   http://xmlsoft.org/html/libxml-tree.html
      this module describes the structures found in an tree resulting
      from an XML or HTML parsing, as well as the API provided for
      various processing on that tree

The fact that the headers requires each-other is related to technical
issues with the C language and an historical constraints, I can't break
application code which for example include just tree.h and call the parser
nonetheless.
I don't see why you mix the semantic of the headers with the way they
end up including each other, the former is what you should care about,
the latter is only of importance for the compiler and me. The semantic
is untangled, in my opinion you have nothing to change to the headers
themselves, the inclusion process itself is IMHO not what you should focuse
on.
If you modify the headers, this won't be libxml2 API it will be the LSB API
and you will garantee its API, not me, I still call this a fork with all
benefits and duties (change of code outside of the normal review process
and without an associated upstream CVS commit with a subsequent public
release is a fork, no matter the reason or who did it, evolution will be 
separate and I won't take this in consideration for the evolution of this
project.)

Daniel

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