Newsgroups: php.internals,php.webmaster
Path: news.php.net
Xref: news.php.net php.internals:78316 php.webmaster:20124
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.213.171 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <544AA546.1010805@gmail.com>
References: <CAHpw9AfyLRPmD6Yr35WNDju83oozVNeu3WyAGJAygBO2SxisEw@mail.gmail.com>
 <544AA546.1010805@gmail.com>
Date: Sat, 25 Oct 2014 03:24:15 +0800
Message-ID: <CADajX4ATU4zyeSJc2AV305hbRawBtgGQdZj0+bnQX+gXR9Jxsw@mail.gmail.com>
To: drgomesp@gmail.com
Cc: PHP internals <internals@lists.php.net>, php-webmaster ML <php-webmaster@lists.php.net>, 
	Rowan Collins <rowan.collins@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Thoughts on the PHP.net website
From: aharvey@php.net (Adam Harvey)

On 25 October 2014 03:15, Rowan Collins <rowan.collins@gmail.com> wrote:
> Daniel Ribeiro wrote on 24/10/2014 19:52:
>>
>> *Disclaimer: *I wanted to bring this discussion inside the internals
>> mailing list not only because of the fact that the PHP.net website's
>> source
>> code on GitHub doesn't have issues enabled, but especially because I think
>> it's part of the PHP environment, just like the spec or the actual C code
>> itself.
>
> In this case, I would have thought either php.webmaster or php.doc would be
> more appropriate than php.internals, which really does tend to focus on the
> internal implementation of the language, rather than how it used or
> documented.

Yep, this is php.webmaster material (I've cc:d that list, and would
suggest that follow ups should probably go there and exclude
Internals). #php.doc on efnet is also a good place to float things
more informally, particularly if you hit it at the right time of day
(morning/early afternoon PST tends to be good, given a lot of the
regular Web site committers are in North America).

> Meanwhile, I agree with both Kris and Andrea's responses: you need to be
> specific about what problems you propose to fix, and you need to be
> extremely wary of breaking existing functionality just because it's
> "interesting" or "modern".

+1.

There are also a lot of technological constraints that aren't obvious
at a glance: not controlling our (entirely volunteer) mirrors means
that the baseline PHP functionality we can rely on is much, much lower
than you may expect. (Don't even ask about databases.) Remember, we
have literally no budget, and rely entirely on the generosity of our
hosting sponsors.

I'm certainly not claiming that what we have in web-php today is good,
but it has the advantage of having been proven over a very long period
of time, being easily and widely distributed, and coping with the
loads that it has to. A rewrite would have to have compelling
advantages over that, and be done for better reasons than just "the
existing code is old and terrible".

Adam