Reasons not to create a new module for "devmanual" now:Should the dev manual have it's own CVS repository with it's own build system? Probably not for the first time. I think it may go into phpdoc/devmanual/* and if it grows to something reasonable, then it should go alone.Any technical reasons to NOT have an own module in CVS and similar/adopted/ported (whatever) buildsystem?
We would probably move the docs and the build system there, and then we will have another copy of the build system, which is even currently gets out of control. Many php related projects have their own docbuild system, which all are forks of the phpdoc system (forked at some point and evolved since then). There were quite many times we discussed our dream on having a unified build system for docs, which is possibly very hard to achive. Counting in that our build system works with the PHP source, while some others work with the PEAR/SRM source, etc. Some use DSSSL, some use XSLT. I don't think so that forking the build system now in another instance is a good idea, and I strongly disagree with it. If someone has a huge amount of time to spend on this, it would be nice to create that unified build system...
> Maybe I'm just in crazy land here, but isn't the developer's manual
> ALREADY in its own CVS module? "ZendAPI"
It is not THE developers manual. The php3 devel appendix and the streams devel appendix is also php development manual stuff.
Note: Not to be confused with phpdoc/en/appendices/phpdevel.xml which is all PHP3 development documentation and should *probably* be taken out of manual.xml.in as it's WAY too old at this point.
And put into the devmanual ;)
It is way much easier to have the files in the phpdoc module until we can create a separate build system (first time probably optimized for this two manuals).IMHO in genaral I suggest a solution that allows an easy and maintainable way of splitting and building, regardless of having an own module/buildsystem or not. The pragmatic way for me: if ist easier to tweak the current buildsystem we should go this way....
OR we can start with creating TWO new cvs modules, one for the build system and one for the devmanual, and just checkout it as the translations are checked out now, alongside the documentation module. So we can start working on that unified build system...
And to avoid search conflicts and general confusion, make a separate website for it. http://dev.php.net perhaps?
+1 :))
I don't think that there are many links from the "user space" manual parts to the "devspace" manual parts. And I don't think there will be any problems with the shortcuts. Dev shortcuts should work on dev.php.net then, and should not pollute the php.net shortcut "namespace" IMHO...I know this is no small undertaking. The general website would have to be built, the www.php.net url search would have to be adapted to the developer manual search, and *most importantly* many <linkend> references in the current user *and* dev manuals would have to be fixed to properly cross-reference between sites.
Well, after we discussed that many guys would like to see PHP 3 stuff in the manual (probably sorted to an appendix), the answer here is probably "moved" and not "removed".I suppose the php3 related dev stuff should also moved?*re*moved maybe?
Goba
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
