Re: [PATCH] --with-ODBCRouter (database networking)

From: Date: Thu, 13 Jan 2005 05:42:14 +0000
Subject: Re: [PATCH] --with-ODBCRouter (database networking)
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-14375@lists.php.net to get a copy of this message
Hi Dan, Wez, Mike, Andi and list: Thank you for graciously debating the merits of our patch, we are honored to receive your attention. As Mac-heads dating back a few decades you can appreciate our pre-occupation with the annual MacWorld events of the past several days, hence the brief delay in responding here. As has been pointed out, there are only a few lines of code contained in the patches submitted for your project community. The net effect of this is to connect PHP into the official Microsoft ODBC Driver Manager hosted on a centrally administered Windows box. We are certain that this is of substantial value to a significant number of your users. In the case of driver vs. driver manager debate, we do not find it useful for clients to have to configure a driver manager on each client, in addition to the central ODBC control panel on the Windows server. The patches we submitted allow for a system whereby all of the data sources are centrally administered in a single control panel on the Windows server and may then simply be referenced by name from any PHP client. If uODBC = unixODBC, please be advised that Apple (with 14 million installed UNIX systems) and many other major vendors have embraced the alternative to unixODBC, called iODBC. We cannot speak for Apple and others, but we do not feel comfortable supporting unixODBC because the principals who apparently control unixODBC also control a domain name called openlink.com which is obviously confusing to clients of OpenLink Software. Besides this credibility issue, there is information on a website at http://www.cinema.com/legal/about.phtml which we find very concerning and so it is unlikely we will ever support unixODBC. As far as some other comments that have been made to these lists about the relative merits of our product, etc.. there are many customers of our competitors products and, well, the above situation clearly spells out what kind of competitors we have and we know they are here as well. Therefore, we don't know what's real in these comments and, in any case, we just don't feel comfortable engaging in that kind of discussion on a PHP internals technical list. We have offered up some 100 no-charge licenses for significant contributors to the PHP effort to put back into the community and so this is not really about money, it is about patches. Thank you again for your consideration and please feel free to present any tech issues to us! Great work PHP team! Tom @ AUGSOFT, 1990->2005->2090 On Wed, 12 Jan 2005, Dan Kalowsky wrote: > Date: Wed, 12 Jan 2005 18:46:24 -0800 > From: Dan Kalowsky <dank@deadmime.org> > To: Wez Furlong <kingwez@gmail.com> > Cc: Mike Robinson <mike@fiddy8.com>, AugSoft <listmaster@augsoft.com>, > Andi Gutmans <andi@zend.com>, internals@lists.php.net > Subject: Re: [PHP-DEV] [PATCH] --with-ODBCRouter (database networking) > > On Jan 12, 2005, at 6:03 PM, Wez Furlong wrote: > > > Regardless of how self important a patch submitter may sound, there is > > no *technical* reason why this patch should not go into PHP; it's not > > as though we have a phobia of ODBC drivers. > > There is a technical reason to avoid it if you've listened to any of my > past efforts to move uODBC forward in time. If it is not a driver > manager, it moves the uODBC further to being a driver manager... > something I have been trying to avoid. I am against continuing the > process of directly linking into database specific drivers, for various > reasons but mostly to cut down on the issues of lack of support. > > You can cite all the rhetoric you want about slowing down the execution > time you want. I don't buy it, nor do I have the time or resources to > continue in the "we'll support everything" manner we're running in. > The end result you've taken your route with PDO, please allow me to > continue my route with uODBC. >

« previous php.internals (#14375) next »