Re: MySQLi

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. > 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. 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? 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. 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. > 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? > 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. Just my 2 cents Georg