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.
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).
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.
Goba