Re: libxml bundling

Zeev Suraski <zeev@zend.com> wrote: > At 14:27 08/05/2003, Sascha Schumann wrote: > >On Thu, 8 May 2003, Per Lundberg wrote: > > > > > On Thu, 2003-05-08 at 10:34, Zeev Suraski wrote: > > > > I see the seconding and thirding and fourthing of this message, but I > > still > > > > fail to understand why people consider the nuance of increasing the > > package > > > > size, something that's completely insignificant for almost all of our > > > > users, as a too high a price for keeping PHP on top of the recent > > > > technologies. Good XML handling is as basic as good forms handling > > in this > > > > day and age. > > > > > > +1 > > > > > > Bandwidth is really cheap these days, as well as hard drives. Who cares > > > about a couple of megs extra? :-) > > > > It's not all about storage; it is about maintability. > > libxml2 is released so frequently that it makes no sense to > > bundle it. Furthermore, libxml2 is basically installed on > > every system released in the last 1-2 years which renders the > > bundled lib redundant. > > I think there are two separate issues then: > > 1. Do we want to bundle libxml. My take on this is that yes, we do - we > cannot rely on the target platform to contain such an essential > component. It's even more important when we see so many different versions > - we'll be doing our users quite a service when we put a version that's > known work well with the current version of PHP, and demonstrate the same > behavior, bugs, etc. I have been wondering what determines how essential a component is for PHP, or for its users. Are you talking about the market's expectation out there? For example, while there are actually certain user base where people ask PHP for more i18n'ed features, it was decided that mbstring should not be on board because of the assumed less demand. In this point, I don't want to take on whatsoever could be called a principle on which we make such decision, since it's totally unfair. Hmm, you might want to say this isn't the deal in this issue... Furthermore, from a QA's point of view, how well does it actually help us assure the same behaviour anywhere, whilst there are lots of uncertainties such as compiler's version? If it's really our job, is it more kind of us to distribute pre-compiled binary packages for any platforms instead of bundling those required libraries? As of the current libxml implementation, it's not completely reentrant AFAIK and it will definitely need much harder work to fulfill the compatilibity and stability. IMO if we really prefer to employ it in ext/xml, we'll have to throw away several amount of BC at a certain point. (domxml extension is another issue... I think that's already stable now.) Moriyoshi