Re: RFC: Self-Hosted PHP Documentation

From: Date: Fri, 16 May 2003 15:34:30 +0000
Subject: Re: RFC: Self-Hosted PHP Documentation
References: 1  Groups: php.doc php.gtk.doc php.mirrors php.pear.doc 
Request: Send a blank email to phpdoc+get-969353535@lists.php.net to get a copy of this message
--- Gabor Hojtsy <gabor@hojtsy.hu> wrote: > > Although noted below as a db-free site, why would this be the case? I > > realize that with mirrors, things can get complicated, but I think an > > architecture with some sort of DB usage, at least at it's core, is vital. > > > You just won't get the speed and flexibility otherwise, IMHO. I have the > > resources to provide some production sites for such an endeavour, or for > > testing/development. > > What speed problems do you think we have currently? I don't know of any > :) Well, we have flexibility problems. But what if we would require some > sort of DB to be installed on mirror sites. Let's say we go with MySQL. > I am sure not all sites would be happy with it. It also sounds very bad > to require one engine. So let's say we use some generic DB, and an > abstraction on it (PEAR DB for example). Then we would need to have PEAR > on all mirrors (a working copy ;). So then would we gain speed with > this? No. Well it's impossible to please everyone all the time; you'll be lucky to please some of them, some of the time. If we were to go to some DB based functionality, we should use one DB - no abstractions, no complexities, with queries tailored to that engine. > Then again, we have 100 mirror sites. What if someone set's his > bookmarks at hu.php.net and it goes down the next week. The bookmarks > will be gone (well, hu.php.net is a real example for a problematic > mirror). OK, so we need to share the data across all the 100 mirrors. > Wooh. All mirrors would need a significantly complex setup (higher > joining requirement to be a mirror, and higher probabilty of problems). I think we'd need to consider the general architecture a bit more. Mirrors don't have to be simply duplicates of the master site; there can be download mirrors, image mirrors, primary and secondary. In our case, there's room for "manual" mirrors and "DB" mirrors. Using a round-robin DNS scheme to access a replicated set of databases would be straightforward and inline with James' suggestion to do the same for the website itself. While some mirrors could mirror everything, that is the website and running a database, others could do only one or the other. > Yet we would not have a great useable offline version for those without > broadband (which is still a very huge amount of people, beleive me). > > So I think we should go on with the offline version, but spice it up > with enough online functions for those who are always online to get the > latest info and still get load off the mirrors, and still have much more > customization options because of the local hosting for users. Personally, I've never used the offline version, but do see it's value. That said, most professional PHP developers are always online from what I've seen - developing a website without being online is a bit of a paradox - and to this end I think providing the richest resource online is most important. If DB usage is valuable at all, I think it would be in a searching, filtering capacity; implementing user personalizations would require more thought, and probably more DB resources (in regards to server power). H

« previous php.doc (#969353535) next »