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.
Yes, you are probably right. The 'problem with me' is probably that I am unable to see the advantages of having syncronized DB mirrors, given the extra care we need to take on those mirrors and the maintainers. We already have 100 mirrors, and have quite some problems with them. Synced DB mirrors would need more care. Does it worth the time? I am not convinced yet. You have yet to show me the very big thing this would bring to us.
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.
We already have local search support on mirror sites. This is not a question of the database. Actually it is much-much better to have a local search support without a syncronized DB. If we would have search indexes syncronized, we would need to sync the data of mirror sites at least twice. We already have the whole site locally on mirrors, so why not index the pages locally instead of syncing the index sparing network bandwidth? We do local indexing currently. Yes, htdig is not the best for local search, mnogosearch is even better supported as a PHP extension. But nobody had the time to experiment with mnogo, and provide a setup howto and an integration kit for mirror sites, which would probably boost the search performance and user experience. But there is no need to have synced DBs for that, acutally synced DBs would be wasting human and network resources in this case.
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.
Seems like you are using the 'DB setup' as a magic word, something which would solve all of our problems :) I would rather like to come to the problem from the user's view. He would like to get fast manual access with the most features he can get, with actual content. If we would have two similar solutions for the problem, we would waste time to take care of both I think. Having an online version with such features, and having a semi-offline version with such features would be two times work. While in my eyes, the semi-offline one would be able to provide all the features we can get with the online one, plus more. It would only need a onetime setup, and then it would update itself as needed to have actual content, and it would be much better customizable then an online one.
Please note that the current manual pages are designed to be cacheable and we greatly depend on caches storing them, so we don't get that much hits. If we would have some level of customization, then the pages won't be cacheable anymore, and our server would be down on their knees in no time, especially www.php.net. Note that we only have a few pages with user specific content (my.php the download pages and the manual language selection page). All the others have the same contents for all users.
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 see one audience. The PHP programmers who want quick access, actual information, great customizability, good search features, etc. As far as I can see, we can provide the greatest flexibility with a semi-offline solution. Having a manual which updates itself if needed, but works even if there is no connection to the internet. Do you think that "those professional PHP users" you mention wouldn't love to have all these after initially setting up the app? Don't you think that the load of these features won't drive them to set up this environment locally?
As for the beginners, we would still have the online manual to start with, and to get to a stage, where they can set up this stuff locally. Or we can put together a simple manual Engine with BadBlue (a very small Windows server) and a stripped down PHP to run this manual offline.
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.
You are absolutely right that the online search is not satisfactory at all. Even PHP developers use alltheweb or google to search in the PHP manual (using URL restrictions there). So the online search definitely needs improvement, and probably not in a htdig based future. Having a synced DB is not a solution for this problem though, see the notes above.
To summarize the stuff, I see that we would like to provide the best service to the PHP users around the world. This is the holy goal ;) In my eyes, it is wortwhile to implement one system which fits [nearly] all users because we only have a limited time to work on this. This is why I have started this discussion to gather the ideas and those guys who can / would like to help. Maybe I am not looking too flexible regarding your idea, but I really don't see the benefit of it. I think every user want the best and we should provide every user the best stuff if we can.
Goba