Re: [xml] libxml2 API crazy?

["Eric S. Eberhard" <eric vicsmba com>]

Daniel said "The key point is the absolute imperative of keeping API and ABI 

stability."

I would add -- ALL changes must be 100% compatible -- with ALL of the O/S libxml2 runs on.  Which is daunting.  The switch from libxml to libxml2 was a minimal change despite a vast increase in functions and usability.  Certainly any "cleaning up" needs to not make people's code not compile.

And making it work with PHP, Linux, AIX, SCO, TI, HP, etc -- you have to be careful and most people don't even have access to a lot of platforms like that.  What works on Linux may not work on AIX or SCO.  And vice-versa.  

Some of what looks like confusion is really "odd code to make it work everyplace" -- I know, a decade ago I cleaned something up on my AIX box and it crashed and died when I put it on Linux.  Then I knew why it was "odd code."

Simple things like the PRAGMA statement are different (otherwise it could solve the padding issue you brought up -- and easy fix is to stop padding altogether and suffer the minimal performance hit).

I suggest, Nikita, that you study and look around some more ... although I see no objection to the example you gave I still would bet if a poll was made, most people already have their own abstraction layer.  I was going to offer mine years ago and that was one issue Daniel reminded me of along with the fact that it was more work than just giving the code -- I'd have to make it work for everything on earth, not an easy task.

E

On 5/3/2013 9:36 AM, Daniel Veillard wrote:

On Fri, May 03, 2013 at 08:17:12PM +0400, Nikita Churaev wrote:
  

list about what you intent to do the most likel outcome is lot of
patches rotting somewhere in a corner of github.
I'm not gonna magically pull your set of patches.
I will review patches if they are sent on this list with explanation of
what they are doing. And before rolling dozen of those get feedback on
the first ones.
      

I originally planned to format a patch with git from my first commit to
last when I get something finished and file it to Bugzilla (or should I
file it here to the list?), with proper explanation.

Actually I'm going to scrap the branch and start anew, without moving
the functions around.
    

 What do you want to achieve ? I think I understand but it is better if
stated. Then we can see how to get there with minimal disruption and
a clear set of patch each doing one step. Probably don't need to scrap
everything, but reorganize in an easy to follow/review set.
 The key point is the absolute imperative of keeping API and ABI
stability. I would also prefer to not add too many new entry points
for both human and technical reasons (first because the API is confusingly
too big already, and second because the resolution of all entry points in
ELF shared library may turn quadratic and we are already quite big)

Beside that I will hadly say no to anything improving documentation :-)

  thanks !

Daniel

  

-- 
Eric S. Eberhard
VICS
2933 W Middle Verde Road
Camp Verde, AZ  86322

928-567-3727  work                      928-301-7537  cell

http://www.vicsmba.com/index.html             (our work)
http://www.vicsmba.com/ourpics/index.html     (fun pictures)