On Fri, Oct 21, 2005 at 10:59:03AM -0700, Jain, Nilesh wrote:
> > 2/ an LSB version blocking on one given revision of libxml2 API/ABI
> > would be the exact same mistake as was done for the RPM integration
> > in LSB, and with a couple years evaluation since that was done, this
> > approach is a complete failure, I prefer to not repeat that with
> > libxml2.
>
> That's why we are having deep discussion, not to repeat the mistake.
good :-)
> > You want a totally white statement, I can only garantee a clear shade of
> > grey
> > and I affirm that pure white is both unrealistic and way too costly to the
> > point of being near useless, potentially dangerous (bugs must be fixed to
> > not
> > end up with broken data !)
>
> I understand this and not looking for 100% white statement. There is
> always a gray area, but it is important to understand how big and deep
> it is.
okay.
> > Now the decision is on your side, I can't really discuss more at that meta
> > level, the thread has been going on deeply enough that I'm out of argument.
> > If
> > you want to examine precise potential changes, then look at the diff of the
> > regressions and ask for them precisely (after haviong looked at them), and
> > then I will explain why it didn't matter or the decision was made, but only
> > on a precise case by case basis.
>
> I think it is very important to understand we should draw the line. The
basically any code which modifies the tree without going though the
API function is potentially at risk one day or another, I try hard to not
break them though, and I don't see any need to change this, i.e. if the
code works with 2.6.22 then it should work in the foreseeable future.
But the line can't be drawn easilly because people have to access the
node directly, for example when navigating within the tree (there is no
accessor function for navigation, i.e. most users of the tree need to see
the structures).
> best approach to include XML into LSB specification is that, we can
> limit the internal structure and interfaces, and only allow the one
> which application is supposed to use or using because other low level
> users [libxslt, etc] are already potential candidate for inclusion in
> LSB. This way we can achieve the stability of specification as good as
> stability of libxml2 for application.
There isn't really a way to split. For example any program using the
DOM need to include <libxml/tree.h> and dereference node->type to process
node based on their type. Hiding the structures would be a awful lot of work,
speed and versatility when processing with libxml2 also comes from the openess
of the library. First I don't really have time for such a work, and second I
think it would not be useful for most of my userbase, i.e. low priority.
> Now I would need your help to identify the what should be included or
> what should not be, work with you on case by case basis.
I already pointed at the header files which I think must be included.
Trying to split them to subpart sounds a lot like an LSB specific release that
noone would use i.e. repeating the rpm fiasco. I guess you don't really like
the answer but I think limiting to the set of header we discussed is already
a first step which I think would be sufficient, going down to "this function but
not that one" kind sounds a lot of work, and there isn't any function that I
explicitely want to break in the future. That wouldn't avoid anything to
the change in the regression tests you saw too, such processing changes will
not be avoided in selecting out parts of the API or even structures, some would
be seen as well if doing just
doc = xmlReadFile("....", NULL, 0);
xmlSaveFile("-", doc);
i.e. the two most core and basic calls of the library.
Daniel
--
Daniel Veillard | Red Hat http://redhat.com/
[EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
[email protected]
http://mail.gnome.org/mailman/listinfo/xml
