Re: RFC: Self-Hosted PHP Documentation

--- Gabor Hojtsy <gabor@hojtsy.hu> wrote: > > 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. > > I am still not convinced that having a DB on mirrors would solve any > problems. What do you think this can solve? [update: we have sqlite db > on php.net and an option for all mirrors to set it up to reduce stat() > calls]. What else would be speeded up and or spiced up with features > with a db? > > > 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. > > Brrr. DB mirrors? Consider that if we reduce the number of current > public all-content mirror sites, people will probably be disappointed IMHO. I can certainly see the hesitation, but again running a DB wouldn't be mandatory for all mirrors. Since being on the mirror list and such, I see a lot of donations for what appear to be well-connected, hefty offers for additional mirrors that are turned away because of country restrictions. These, or other mirrors, I'm sure would be happy canidates to provide such a DB mirroring scheme. > > 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. > > It is not a problem if a site is not updated for a day. It is a problem, > if user settings are not syncronized on all mirrors. If we would have 10 > mirrors with user settings synced, then the other mirrors won't be used > at all for manual browsing, as they would be much less useful then those > 10 mirrors. So then we would reduce our mirror base to ten 'useable' > mirrors. We certainly cannot coordinate all the current 100 mirrors to > have a DB installed and be always in sync. I agree, thus my reasoning for not implementing user settings at this time, but rather only to use DBs for searching functionality. After this initial phase is operational, we could always look at extending it with little cost, since there would be a network of DBs operational. > > 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). > > Searching is already supported. What filtering are you talking about? > Isn't that part of the "personalization which would require more thought"? > > You probably cannot imagine the real value of offline manuals. You have > not followed the PDF requests probably. There are many developers out > there who are not using any digital version, but they print out the > whole manual. There are also many developers who simply cannot afford to > be online (plenty of them in Hungary). I used to be an 56k modem user > till the end this march, not because I was unable to pay for broadband, > but because there was no other option. My connection bills were very > high. So don't only count with the US, we are serving the whole world! > > With my proposed solution we would have a > - distributed manual which would > - work offline, > - without any requirement to change the mirrors locally > - with automatic update to have the latest content offile > - with any user preference one can imagine based on offile data > - and it would also reduce the hits on mirrors because of > the offline manual > > And it would also offer a standard integration interface for other [PHP] > projects to plug in their documentation. Many guys need PEAR or ADODB or > Smarty docs by the side of PHP docs to write their apps, don't you > agree? The php site won't integrate with ADODB or any other third party > project I can assure you. I agree, but perhaps we are talking about two different issues. Like I say, th offline manual is certainly valuable, but I don't think it has to be instead of a DB setup. > So why to reinvent the whole mirroring structure, add more work to > mirror maintaners, put a higher level for mirror acceptions, when we can > create a better solution without disturbing the mirrors and with adding > more options to users. Well, some of these are factors. Adding a DB would require a slight shift in mirror setup and organization, but since not all mirros would be required to support a DB, many of these aren't issues. > The only negative point in my proposal is that readers need to have a > web server and a PHP installed (maybe with a database too, but I am sure > everything can be done without it, there are quite cool binary file > based native search solutions). But you said your target is professional > PHP programmers. So do they have a webserver and a PHP installed? YES ;) Perhaps I'm confused. If we go to a distributed offline manual, wouldn't the whole purpose be to not require a web server, DB or anything similar? I see two distinct audiences; those who need the offline manual for reasons you've stated above, and those professional PHP users (or at least those who have constant Internet access). I think an offline manual (a sort of "compiled" manual) and the online version, with fulltext searching, etc. would address each of these audiences. I just wanted to throw out a couple ideas, mainly because I find that searching for things that I know exist in php.net's manual simply return no results. Maybe simply another look at using binary/static web site searching would suffice. Just something to kick around. H > > Goba >