Re: my worry about the recent libxml change

[Daniel Veillard <veillard redhat com>]

On Fri, Mar 23, 2001 at 12:31:22PM -0800, Maciej Stachowiak wrote:
> 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.

  And since I could not change libxml1 API I had to work on a separate
branch, yes. Where I did fix the problem. Accusating of not having
done my job is perfectly unfair. I did it, hoping that people would switch
within a reasonable time frame, not 2 years !!!
  
> > > 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

  And why I urged people to switch to libxml2.

> 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.

  And a very reduced encoding support and with a broken I/O system
and .... I managed to make a successful and compliant library widely
used but this was not possible in the framework of the libxml1 binary
API. Again I wasn't told that you would take 2 years to switch to a decent
I18N framework.

> > [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.

   BZZZZZZ WRONG, check your facts first !
   libxml-1.8.12 do read the broken ones and assume ISO-Latin-1 
in this case. But it will keep an UTF8 internal format and save
only to UTF8.
  I did test this with galeon before doing any tar or advertizing !!!

> 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.

  No I was never happy about this I urged people to switch to get
something decent. The only thing is that now I have some support to get
this rolled in.

> 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 disagree, I think it's perfectly acceptable to release 1.4.1
with a decent fix

> 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.

  Is this your last word ? You are ready to make a final decision
for which you will have to appreciate the consequences, while clearly
you did not check all the technical bits.

> 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.

  Short term == nearly 1 year. You don't want to fix bugs. But you
are ready to get stupid kludges like gnome-db2html2 using an XML
parser to parse the SGML docs get rolled in in such a release claiming
it passes QA and so on. Sorry it doesn't even pass the basic sanity
check I would expect from someone with experience in the field.
  If you expect this to be the way to make people believe in a
technology, it certainly won't convince me, I may not be the only one !

  Again I don't want to block 1.4 but if you persist to refuse the idea
of getting this fixed in 1.4.1 in a reasonable time frame then I think
we don't have much more to exchange.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/