On Fri, Aug 30, 2013 at 10:56 AM, Jordi Boggiano <j.boggi...@seld.be> wrote:
> On 29.08.2013 09:52, Zeev Suraski wrote: > > I have to say that I'm not wildly enthusiastic about making this change > over > > what appears to be a fairly minor comment in the license, and without > even > > going into the discussion as to why we want to promote Evil :) > > > > The main concerns I have are: > > * Downwards compatibility. We've found one potential issue, how can we > > guarantee that there aren't others when we deal with a completely > different > > implementation? I think that users that bump into apps suddenly > breaking in > > obscure edge cases will not be very understanding when we explain to them > > that we did that over a licensing quirk - that I'm willing to bet they'll > > say isn't applicable to them... > > * Performance. Again, for the same reasons, I think it'll be difficult > for > > us to defend this decision in this context as well. We switched to a 2x > > slower implementation over this? Really? > > > > I think that a better alternative would be enabling ext/jsonc to take > over > > the ext/json symbol space so that people who care about the license > issue, > > and/or are interested in the extra features - will be able to take > advantage > > of it as a drop-in replacement. Debian can come with this switch turned > on. > > I think it'd be best to resolve this in PHP because otherwise it means > Debian (& Fedora?) users will have the bad surprise of a quirky > implementation when deploying to prod, and I can imagine the > impossible-to-reproduce issues that will follow. > I would say, to stay in the pipe, that then it would be a Debian issue, not a PHP one. > > That said, your last proposal of at least having a switch in php like > --enable-evil-json sounds better than the current state. If we do have > an equivalent implementation though we might as well throw away the > existing one instead of keeping two IMO, but that's a detail. > Seems good. Julien.Pauli
