Ok, I think I need to clarify here. The only patches we have for the ported application is to remove the deprecated, internal interfaces or the ones that are not in LSB. E.g. raptor is using nanoHTTP interfaces that we need to change. The patch is not for headers or includes. For an application to become LSB compliant we typically find such a need. Most of the time, the usage of deprecated symbols (and the ones not included in LSB for some reason) need to be replaced. Same case for libxml2.
And another clarification regarding fixing in 4.0: I did not mean that we will change the standard, but just its organization. If the feedback is LSB provided headers are bad or incomplete or just not good for whatever reason, we can always go back to upstream headers without really changing the standard. All we will be doing is reorganizing it. We always have the option of specifying all interfaces, types and #defines in a single section without any organization. This is as far as the spec is concerned. Again, this is not changing the spec, but just reorganizing it. In this case, LSB will just recommend using upstream headers. The problem here is what I mentioned in my earlier email: How do we tell developers to avoid certain things (types, #defines and symbols) during their development? There is even another option: Keep the spec as it is now and still supply upstream headers to application developers. That way spec will remain organized, but there will be no "fork" for the headers. We still have the problem of "modifying" the upstream headers to hide the non-lsb symbols and types. Anyway, I do not want to alienate upstream by standardizing the concerned library. That is really the last thing we will do. The only reason LSB desktop project is interested in libxml2 is because it really has become the best practice and we just like to formalize/endorse it. The intentions have not changed since our discussion during OLS last year. Thanks for your help and feedback. -Rajesh > -----Original Message----- > From: Daniel Veillard [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 05, 2006 1:28 AM > To: Banginwar, Rajesh > Cc: [email protected] > Subject: Re: [xml] LSB specification for libxml2 library > > On Wed, Jan 04, 2006 at 06:21:08PM -0800, Banginwar, Rajesh wrote: > > Given LSB infrastructure, we tried to keep the organization of headers > > intact (e.g. we moved xmlParserErrors to xmlerror.h), but failed in few > > cases. As a check, we ported few applications like xlog, raptor etc. to > > these new headers without too many problems. > > Ideally there should be no inclusion problem, we will see ... > > > > The only pointer to xmlsoft.org is a normative reference but it > > > describes > > > libxml2 upstream information, with a different set of headers, how can > > > this > > > be normative too if different ? One frequent question here is how to > > > capture > > > and handle errors in the toolkit, and the canonical answer is to point > > to > > > the > > > error.h header defining the functions, data and constants needed to > > > process > > > those, but this header don't exist in your list, and I'm not sure all > > the > > > data it exposes are also available. > > > > I think you meant xmlerror.h and it is in the spec. > > okay I missed that. > > > > Nothing new, I'm worried by the changes made to the headers, and how > > the > > > users are supposed to deal with two distinctive version. The fork > > > generated > > > doesn't seems in my opinion to be in the users best interest, the side > > > effects > > > being either confusion, or wasted efforts depending on how much > > traction > > > the > > > LSB variant will get. It's hard to predict how useful it will be and I > > > would > > > have preferred to be more enthusisatic about the LSB endorsement. > > > > Next few months, we will have the specification reviewed and used by > > some of the application developers. The only reason we are creating > > these new headers is because not everything in libxml2 is in LSB. I > > would have loved to keep the organization of headers intact for the part > > that is in LSB. But it was not possible to do so as all headers are > > auto-generated from a mysql database (which contains all symbol and type > > info). The DB provides the central repository that we use for all our > > tools (including headers etc). > > So you have an internal infrastructure problem which is the reason for > an external fork of the code base, i.e. a long term nightmare. The obvious > answer is really 'fix your tools' the amount of damage due to the fork > can't really be justified by an internal database format problem. > > > If this turns out to be a bad thing (as you fear) for users, for LSB4.0 > > timeframe, we will need to find a different solution and avoid these LSB > > specific headers. > > You had to patch the applications you compiled against the LSB version > of libxml2? If yes, then you know it's a bad thing, you don't need to wait > IMHO. I have been in the standard business since 98 (XML @ W3C) and if > there > is a lesson I have learned is that 'oh, we will fix that in version 2' > just > doesn't work, precisely because for a standard to be useful, it must be > cast in stone, if you need to wait for LSB4 to do it right, then consider > waiting. I have seen the mess it is to retrofit new changes in an already > issued standard (xml:base and xml:id in XML-1.0), I would rather avoid > seeing > this for libxml2 too. Maybe it's too far streched to be relevant, but this > does not sound good to me. On the other hand if the applications > recompiled > as is without troubles, then okay, I will just keep my finger crossed ! > > 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
