Re: Bundling libxml2 and expat compatibility layer

On Sun, 2003-05-04 at 16:59, Adam Dickmeiss wrote: > On Sun, May 04, 2003 at 11:21:19AM -0400, Sterling Hughes wrote: > > On Sun, 2003-05-04 at 08:36, Adam Dickmeiss wrote: > > > On Sat, May 03, 2003 at 12:11:14PM -0400, Sterling Hughes wrote: > > > > Hi, > > > > > > > [snip] > > > > > > > 3) Proper unicode support > > > What is it that Expat misses? > > > > > > > Exactly what you said. :) It doesn't handle these encodings natively, > > libxml2 does. Libxml2 can detect proper XML encodings, character sets, > > and use the appropriate functions. It also natively detects and uses > > iconv() to do encoding transformations. Its not that expat can't be > > made to properly support unicode, but it can't be said that it does. > > Strickly speaking libxml2 doesn't do the conversions either. Both libs > use iconv which is just fine. As I said a number times, the fact that > Expat does not interpret encodings is due to ("bad") code in ext/xml. > Well, strictly speaking ;-), expat doesn't support UTF-16, libxml2 does. > Will people still be able to configure PHP to use Expat for the basic > functions (old xml) or will that wrapper disappear? I too am a little > worried about performance. We have an application where many XML files > are parsed to produce just one HTML page and we're probably not the only > ones to do that. Don't worry about Dmitri's claims, they are as bogus as bogus can get. Libxml2 is equally as fast as expat (its a matter of a few clock ticks difference.) But, as I stated in my original message, both expat and libxml2 will be supported - in fact, that's the whole point of the bundling schema, and the expat compatibility layer (C level). -Sterling -- "Whether you think you can or think you can't -- you are right." - Henry Ford