Hello, on 08/03/2006 02:52 PM Kilbride, James P. said the following: >> I admit I have not expressed myself clearly. What I meant is >> not that people should be disallowed to implement alternative >> APIs, but rather that they should not feel the need to do it. >> >> In the Java world, JDBC is the de facto standard because Java >> developers do not feel the need to develop other database >> APIs. That happens because JDBC is a standard API defined by >> several players from the SQL database world that sit together >> and defined a consensual API specification. > > This is partially true because Java is owned and managed by SUN, and SUN > is all about developing API's, both to ensure that it's own later work > will work, and because it meant a better way for people to interface.
I do not agree with that. Many Java API are defined by many parties besides Sun. For instance, the JDBC specification was defined by an experts group from several companies listed here: http://www.jcp.org/en/jsr/detail?id=54 > By the same token Pear_DB, and the follow ons were much like the early > versino of JDBC. As is PDO in a lot of ways. The majority of the > database specifics have been abstracted out and a general interface has > emerged. Unlike in Java though, the PDO and Pear_(M)DB(2) families > haven't settled yet(nor did JDBC overnight) but they are being developed > by the community. And many people DO recognize the advantage of The matter here is not PHP versus Java. The matter is using APIs defined in consense with several interested parties of the community. The PHP community is very uncooperative. Let me give you an example. It happens that I am the Metabase developer. Metabase is the base of PEAR::MDB. PEAR::MDB2 is the follow-up of PEAR::MDB. Before PEAR::MDB existed, I invited ADODB author to cooperate and develop a common PHP database instead of keep copying Metabase features to provide the same functionality with an incompatible API. He refused to cooperate without giving a proper reason. When I tried to submit Metabase to PEAR, it was refused with all possible lame excuses that PEAR people could find then. They demanded a complete rewrite to match their style guidelines. That was completely inviable to me as Metabase had already over 12,000 lines of code. Instead I proposed that somebody does it. Fortunately Lukas Smith was brave enough to accept the proposal. It took a lot of time to convert all the code and many bugs appeared when none existed due to normal human misunderstanding mistakes. Meanwhile Metabase continued to evolve and PEAR::MDB too, but independently, hardly benefiting of mutual efforts. Several tools have been developed around each API. Tools for one API do not work with another API without a signficant conversion effort. It would have been much better if all parties have sit together and cooperate in defining a consensual API. I am not even talking about having a single API implemention. Different implementations could exist based on the same API specification. It would all have been much better for all the PHP community. > But you could argue, how is PDO not a standard interface like JDBC? How > was it not designed by the community and put out there for people to > implement their own methods for it? Forget PDO, it is yet another attempt to succeed where PHP ODBC and DBX extensions have failed. PDO is not based on consensual API specification. Therefore, it is ill fated to be used only by a fraction of the PHP users. The same goes to Zend Framework and other unilateral developements. That was the point of the blog post. While different API developers do not open their minds and cooperate with each other, nobody will benefit from consensual API specifications in the PHP world. -- Regards, Manuel Lemos Metastorage - Data object relational mapping layer generator http://www.metastorage.net/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
