Wait a sec, As a previous maintainer, I dont believe I should really have as much weight in this decision as the rest of the internals group. It does seem like plenty enough discussion over this INI business. Theres now over 40+ mails on this thread, mostly about ini. And this is not the only discussion we ever had about this either. I agree with Stainslav that we shouldnt let it go unresolved because... well, because thats exactly what happened when we discussed ini files for FPM last time.
Overall, it seems the positions of Stainslav and Zeev are generally representative of this thread. I don't have any worthwhile arguments throw against those views. They all seem balanced and well intentioned enough. And it would be great to draw a line under the whole RFC. Ie by stating that we only need to add just 1 specific feature to FPM to get it officially accepted. Now that Zeev (and if not Zeev then Stainslav) have been kind enough to openly commit to writing a patch for this, thats absolutely great progress. Of course we also dont want to miss out on all the major rewrite work Antony has been doing recently with FPM, which is also absoultely essential to a future with FPM. Its understandable to be worried about letting the standards of the code slip, when Antony has been trying so hard to clean up the existing codebase. So its not unreasonable unreasonable to be a little concerned that we would make the code harder to maintain by including INI syntax. Some of the struggle seems not adding INI, but adding it in a way thats clean and easy to maintain. On the other side of the coin, rejecting Zeevs offer for a patch would mean failing to satisfy the RFC consensus. Surely we can know what kind of good code to expect with Zeev and Stainslav here, based on their past work for PHP? If the problem is all arguing over these finer points / differences then id suggest that those seem less like big issues to the rest of us. Either way, this INI thing does seem to be pretty much the only thing people are asking for here. So it seems accurate (to me) to label "any reasonable INI syntax" as the 1 resulting RFC consensus? That would mean the RFC is not necessarily be an outright requirement to remove the xml. I mean you might conceivably want xml to remain for a while as a legacy option. Or have it the other way round, where the INI option is disabled by default until we are confident that it properly satisfies the RFC. On Wed, Mar 24, 2010 at 8:46 AM, Antony Dovgal <t...@daylessday.org> wrote: > On 24.03.2010 11:29, Zeev Suraski wrote: >>>I think you're missing something. >>> >>>I don't care if FPM is in or out of the core. >> >> FWIW, I don't think it's a good start for a component that goes into >> our distribution. >> In this case I'm willing to take responsibility for doing the >> conversion, but for the record, if someone proposes to put a >> component into the PHP distro and refuses to implement the feedback >> (not every last piece of anecdotal feedback, but the key points) > > "Key points" is exactly what under question here. > Taking into account that the maintainer of the branch (along with other > people) agrees with me, > I tend to think this point is not so major as you think. > > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
