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

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
      tree: interfaces for tree manipulation
      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
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
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


Daniel Veillard      | Red Hat
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]