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? > I >don't see any sense not supporting the latest available libxml2 version >(they bugfix and speedimprove it constantly), but just some version, we >think is stable (libxml2 was never a problem recently with stability). >And at the moment, we do not support zillions of libxmls, but only >versions greater than 2.4.14 (which had unfortunaly a little api-change, >so we can't support lower versions anymore) Well, I'm not sure how this translates, but there's a saying that if you try to get it all, you end up getting nothing. One of the two big issues people had with libxml's bundling is the fact that it's a moving target, so it would be a headache to bundle. I'm definitely not in a position to say whether that is true or not, but I know that taking a certain version and sticking to it can't be much of a problem. If we end up seeing that taking the latest version at each release (we release every few months now, not every other week!) is not difficult either, there'll be no reason not to do it. The other problem is the download size, and I don't believe that is a real issue, considering the importance of this library. > > We need to address the symbol clash issue, and that's about it. > >Does this mean, we are not able to link it to an already existing external >library anymore and we always include it into the executable (adding 1.5 >MB to the exec and not sharing it with other programs), or do i really >miss something (hey, it's early...)... Furthermore, if we support linking >to an external libxml2.so/.dll, we have to support new versions anyway ... 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 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. Zeev -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
