On Jun 9, 2011, at 1:33 AM, Hannes Magnusson wrote: > On Thu, Jun 9, 2011 at 04:22, Rasmus <ras...@lerdorf.com> wrote: >> On 06/08/2011 10:53 PM, Philip Olson wrote: >> obvious way to game the system. Simply write a trivial extension, stick >> it in svn or put it on github/codeplex/wherever and now you are in. And >> in fact Azure has such a trivial extension: >> >> http://phpazurecontrib.codeplex.com/wikipage?title=php_azure.dll >> >> so even if we tell Craig not to put the Azure thing in the install >> section, he can simply submit documentation for the extension and put >> his Azure install blurb alongside his extension installation docs and > > We only document "pecl installable" extensions (some cases exist where > the ext author doesn't want the docs on php.net though). > > I do believe it is important for the docs to not document everything out > there.
I understand it's only an example, but as Hannes mentioned we require extension packages to be available at pecl.php.net, so it's not completely arbitrary because we adhere to PECL rules. >> everyone would be happy. However, if we take an honest look at this >> rather arbitrary restriction of only allowing extensions to have landing >> pages in the docs, it is exactly that, rather arbitrary. > > I don't know what this means. > Each extension is considered as its own and complete book. > > The mysqlnd docs for example utilize that fact very well and provide > all sorts of info. Most new contributions involve PECL extensions so that's what we document. Adding hosting services is a new idea so that's why we're pausing and planning for where it may go and look like in the future. We do, for example, already document how to install PHP using Debian packages. >> I think a better restriction is whether a topic is of general interest >> to PHP users. And here I think documenting how to install and use PHP >> with the various cloud services is something that is genuinely >> interesting to many users. > > > As for 'installing in the cloud'.. Sure. We could treat it as just > another platform we can install PHP on, and document accordingly. > However. Don't all these services use their own patched PHP? - By > documenting "apt-get install php" and such things we are effectively > officially recommending people to not run vanilla php, but whatever > the distros decide what PHP is... I don't see a problem documenting non-vanilla PHP goodness but fact is, the PHP Manual is huge and parts become outdated and cluttered. But I think we've concluded that documenting cloud services will be okay, just as long as they stay focused and remain related to PHP. As for location, a cloud platform section within install comes to mind (e.g., install/cloud/azure.xml, install/cloud/ec2.xml), along with a cloud specific entry somewhere like features/ although either a FAQ entry or install/cloud/index.xml may be enough for that. For now, I propose we add install/cloud/ and Craig edit install/cloud/azure.xml so unless there are objections then I'll add this framework. Regards, Philip
