Hi! I have promised to write up this RFC about the service plan in my mind, codenamed "My php.net".
What would be "My php.net"? --------------------------- My php.net would be a user preference service. Utilizing this, every user of the php.net site and mirror sites (plus maybe other php.net subsites, eg. bugs.php.net) would be able to set his/her own preferences regarding a wide range of things. The starting point for this was the "mirror language", which can be set by mirror maintainers now, and affects the URL shortcuts on mirror sites. The idea is to go beyond that, provide the user with control, and broaden the range of things available for customization. Customizing the php.net site ---------------------------- The core offer of My php.net would be to set the preferred language [PL from now], and the preferred mirror site [PM]. [PL] would be considered in all kinds of operations, when a language selection can be made (documentation search, URL shortcuts, book page display, documentation downloads page language focus display, etc.) [PM] can be used to redirect the user to his/her preferred mirror site in some cases (read on). Requirements ------------ - Settings should work on all php.net mirror sites, probably even on unofficial ones. With the possible (or partial) exception of www.php.net (read on) - Caching should not be sacrificed significantly. That means, that most of the pages should look the same, regardless of the user settings. This means that things like previous search term display in the search box, or manual page display modifications would not be allowed. If we enable users to set anything that modifies the display of most of the pages, and that means different HTML code sent out, then we can throw out caching, as every user need to get his own page instance. That would bog down servers. - Preferences should work without any hassle (no complicated authentication for example) - Do not increase traffic on http://www.php.net, continue the trend of driving traffic out to mirror sites Implementation -------------- As the above requirements say, it should be easy to use, and work on all mirror sites. The easiest way to go is to use a cookie to store the information. Then there is no need to log in, and as all mirror sites (with one exception) are under php.net now, the cookie can be set to be available for all mirrors (like the cookie you get when you log on to master.php.net). The cookie should be very small, and set for a long period. There is plenty of space in a cookie if we code the settings in a short form. [PL] would be considered as part of the soon to be used new unified language chooser (phpweb/include/langchooser.inc now in testing phase). That code correctly show you how the different environments are taken into account, when the language to use is selected on any php.net page. The place for user settings is also marked. [PM] has it's own great value. First of all it would be a default mirror for downloads, so users will never need to select a mirror site again for downloads, if they have [PM] set. For another neat thing about this, read on ;) My.php.net ---------- Well, the settings need to be set somewhere, so I thought about adding a my.php file to phpweb, therefore the settings page will be accessible with php.net/my. I also thought about making this even shorter and cooler, and ask for my.php.net to point to this page. Then it seemed much better to make my.php.net an entry point for the automatic mirror selection, and redirect any URL accessed there to that same page on the [PM]. This address would also be used for the special CHM, eliminting the need to set the preferred mirror there. As I have thuoght about this, error_docref was addeed, and php.net was choosen as the default for that feature. As most of the guys won't modify that URL in php.ini, this has driven more traffic to php.net, though probably less traffic to php-general :) Therefore I thought about making php.net the mirror redirection server. This means that if you would like to access a page on php.net but you have a different [PM] set, then you are redirected to that site instead. That would drive much traffic off php.net again :) The other point worth considering here is that if we add [PL] as a setting, then php.net gets more traffic, as users don't need to go out to a mirror site for easy shortcuts to see manual pages in their native langauge. Therefore we need to disable [PL] on php.net, or remove php.net from the selectable mirrors list, and always redirect from php.net. The later is a bit too agressive, I think the former can do what it is proposed for... Or else, if the php.net systems team does not care about the increased traffic [PL] will cause, we can leave it to work on php.net normally... Summarizing this section php.net can be the redirection server, if you have a different mirror site set in [PM]. Other mirrors won't redirect to [PM]. This also makes my.php.net unneeded, or it can point to the settings page on [PM] :) More settings ------------- We can add more settings in the future, as these two core ones are added and work ;) Some ideas: - Default bug email address to submit bugs with - Default user note email address / name to submit notes with - Do fall back to a mirror site in the same country if [PM] is disabled for some reason, or choose a random mirror site instead - ... Workaround ---------- While the second requirement above is the most restrictive, some pages will look differently tailored for user preferences, like the docs-download page will highlight the manual row for [PL]. However our manual pages form the biggest part of the site, so they are to look the same in all circumstances. Actually they don't need to look the same, but they need to use the same HTML code. We can add JS parts to work with the preference cookie in JS, and do something differently, eg. drop out the left side manual toc using client side DOM. We can also include a JS file on the top using <script>, and put all the user depandant things there, so the PHP page output can be cached, while that JS will be outputted from PHP with non-cache headers. This is something for the far future, and I think some of you won't be too keen on the idea, so this is also up for discussion... What have I missed? ------------------- I have probably missed a point or a few points to consider, so if you know of anything better, share your knowledge / ideas ;) Goba -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
