Re: [PATCH] --with-ODBCRouter (database networking)
| From: | AugSoft | 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.
>