Re: MySQLi

On Fri, 23 May 2003, Georg Richter wrote: > On Friday 23 May 2003 00:39, Philip Olson wrote: > > On Thu, 22 May 2003, Georg Richter wrote: > > > On Thursday 22 May 2003 22:28, Philip Olson wrote: > > > > There is no information on how to install mysqli, > > > > how to configure it, what it is, what php and mysql > > > > versions are needed ... nothing. Until this happens, > > > > it doesn't seem worthy for any generation and will > > > > only lead to chaos and confusion. > > > > > > It's EXPERIMENTAL for PHP5 and I don't see a reason to remove it cause > > > there are currently no installation instructions. Several people are > > > working on the documentation already, and also some people are using > > > (better testing) ext/mysqli already. > > > > MySQLi was never added to manual.xml.in. People are > > working on the docs, that's good, but imho reference.xml > > is not ready enough for this to be generated and will > > cause more confusion than good. > > Ok, that was some kind of misinformation then. In other words, let's add to > manual.xml.in. I'm all for adding it after John is finished fixing and adding the reference information. > > Every extension listed in the manual has proper > > information in reference.xml and friends. It won't > > take long to add simple information like that mysqli > > requires mysql 4.1+, or that to compile it you use > > --with=mysqli (or whatever)... It's an important part > > of the documentation especially for popular extensions > > like mysql. The fact that there are now two mysql > > extensions is confusing enough. Anyway, John has > > agreed to add this information. > > No, take a look of ncurses. People used it, when there were only protos > available. I started to document some functions, and "new" people, developers > and php-doc people contributed documentation too. It was never complete or > had complete information. We should also cover extensions which are > experimental, and which aren't ready neither in code or documentation. ncurses looks fine, it mentions --with-ncurses and even links to the ncurses sources. I think we are miscommunicating here or something, I'm not saying wait until every function is documented or whatever... just the raw basics like the requirements for using the extension. > PHP-Documentation is not a book for a final version, it should cover also new > ext's. And how people which aren't involved in dev or doc should know, that > there is a new extension available? They will know when the bare minimum documentation is complete. To me all this means how to install the extension, what is required, basically, a proper reference.xml, ini.xml, and configuration.xml Everything else is a bonus. > If you like to have some quality in the manual, throw away most of the > incomplete and wrong extension documentation, the outdated Zend-API and parts > of most of the translated and incomplete manuals. Quite a job indeed. Soon some extensions will be removed and on the TODO is the separation of the developers part. > Also, we should add > > to the ext/mysql docs that they won't work with 4.1+. > > It works fine, but it depends on your configuration. If you decide to use the > bundled lib with 4.1 server, you will run into several authentication > problems of course. I look forward to this documentation ;) > > And less importantly, the reference.xml currently holds > > all constant information with most entries listing the > > constant name as also the value, that's weird. Also, > > why does there even need to be a constant values column? > > Right, I can't see a sense too - maybe Hartmut or Goba have a clue? Let's just remove them. > > The topic of which extensions should be generated is > > another story, and BC comes into play. > > I don't see a BC problem - we have the same problem with two oracle > extensions, which aren't compatible. The ext/mysql supports an optional last > parameter, which is a link - this makes it nearly impossible to support > future releases of libmysql which added additional parameters to functions. > If people don't need MySQL's fast and powerful api-features which were > implemented in version 4.1, they still can use ext/mysql without any BC > problems. Changing ext/mysql to support MySQL 4.1 api would break BC. I wasn't talking about mysql there, but BC concerns for removing documentation. For example, simply deleting cybermut isn't the best answer. Regards, Philip