Re: my worry about the recent libxml change

[Maciej Stachowiak <mjs eazel com>]

Daniel Veillard <veillard redhat com> writes:
 
>   Again I have expressed this was a libxml1 problem for one year, 
> and urged people to switch to a compatible parser like libxml2.
>

However, you didn't fix libxml1 during the course of that year. And
now people have come to depend on the long-standing buggy
behavior. And it's hard to blame them, since there was no way to get
it right with the old libxml1.
 
> > Making libxml DOM trees in memory always use UTF-8 will break all the code
> > that puts strings in and takes them out without doing any translation.
> 
> It wont break the code, it shows the code is broken, significant difference.
> I don't want to break your code, but i want it to be fixed, I will help
> people to transition like I have said one year ago when releasing the
> first libxml2 version. Point is until recently nobody gave a fuck about
> what I was saying, you get more pressure now, well I'm sorry ...

The problem is that with the old libxml1 it was impossible to write


You kept claiming that everyone should switch to libxml2 and break
platform compatibility, but you just showed that it's possible to
write a library with a conformant parser and the libxml1 API.

> > I don't see how to make a program that works compatibly with both the old
> > and new versions of libxml. I have no idea how to address this issue in the
> > code for the various packages.
> 
>   you can test xmlParserVersion exported by libxml1 and libxml2 and act
> to use the translation where needed i.e. when the string value is > "1.8.11"
> 
> [root rpmfind /root]# nm /usr/lib/libxml.so.1.8.11 | grep xmlParserVersion
> 0005528c D xmlParserVersion
> 
> [root orchis /root]# nm /usr/lib/libxml.so.1.8.12 | grep xmlParserVersion
> 0004d58c D xmlParserVersion
> 

But it's impossible to write data files that can be parsed by either
version as far as I know.

> > I hope someone can prove with testing or coding or both that I am wrong, and
> > this change can be done compatibly.
> 
>   I hope it can too. But if the final question left is:
>     "Shoudl we prefer keeping the existing broken platform over
>      adherance to standard and better I18N support"
> 
>   then my definitive answer is a resounding NO ! 
> I just hope we won't end up being stuck at this question.

You seemed pretty happy to keep the old platform broken for a long
time. Now is a very bad time to suddenly completely break the world in
the name of standards complicance.

I propose that we stick with the old plan and hit standards
complicance when we ship GNOME 2.0, instead of suddenly changing the
plan and creating a huge last-minute fire drill for everyone.

I will definitely not accept a libxml1 that breaks compatibility in
this huge way into any GNOME 1.x release as long as I am a release
coordinator, or any application that depends on it.

We have the platform compatibility rules for a reason and many times
we have refused bug fixes because they would break compat. Here we
have a clear-cut case where people were depending on the old buggy
behavior. In my book, that takes precedence over short-term standards
compliance, which we can fix in GNOME 2.0 as originally planned.

-- 
Maciej Stachowiak <mjs eazel com>
whacky-ass code cowboy[sic]
Technical Lead, Services Engineering
Eazel, Inc.