On Sat, 1 Jun 2002, Zeev Suraski wrote: > At 12:45 PM 6/1/2002, Christian Stocker wrote: > > > I believe that bundling at the makedist level makes the most sense, > > because: > > > (a) Synchronization is trivial > > > (b) We get to choose what libxml we use, so our libxml-dependent code > > > doesn't have to support the zillion different libxml's out there (the > > > moving target argument, in my opinion, is a good reason for us to bundle a > > > stable version of libxml rather than support all versions out there) > > > >I do not agree with that. libxml is a moving target feature wise, but they > >really try to keep the api stable (they do not succeed always :) ). > > Feature-wise in a way that the wrapper module code won't have to change in > order to take advantage of?
yes, bugfixes and speed improvements. We don't have to change the wrapper module to take advantage of speed improvements in libxml2 or for example bug fixes in the xpath implementation (2 issues currently discussed at the libxml mailinglist) But also feature-wise in adding new features (for example xml-schema support). Though, the php-module does not take advantage of this without adding new functions ... > I guess it depends to the answer of my first question - whether new > features will be transparently available to users, even without changes to > the wrapping PHP module. If that's the case, we probably should think of a > way to support the local library, probably in the same way we handle > MySQL. If (!!) we bundle, then this is the only way to go IMHO > If not - I see no problem in always using the bundled library, > regardless of what's already installed - on the contrary, I see a fairly > big advantage. I see really no advantage in this approach (more memory needed for example, maybe symbol clashes and all other reasons from sync-hell i mentioned in my previous mails ) chregu -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
