Re: Bundling libxml2 and expat compatibility layer

> > Well, strictly speaking ;-), expat doesn't support UTF-16, libxml2 does. > Exactly:) Expat supports UTF-16. But for whatever reason the coders > of ext/xml didn't like it. > No, expat itself does *not* support UTF-16 - not really. It allows everything to be handled internally as UTF-16, but it requires you to be unicode safe as well. libxml2 allows the document to be in UTF-16, however, you can handle it as UTF-8 (or ISO-8859-1). > > > 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). > A few hundred thousand ticks probably. Time will tell. It's > a win-win when one can choose either. So I'm happy. > Yeah, but a few hundred thousand ticks is nothing. > I can't seem to see your new stuff in CVS, yet. Right? > Yep. Unless objections come up, I'll commit it before I head to amdam on tuesday. -Sterling -- "A business that makes nothing but money is a poor kind of business." - Henry Ford