Re: Some free utilities for Java, with Hebrew support.
On Sep 23, 12:48 pm, bbo...@gmail.com wrote:
On Sep 22, 10:09 pm, Owen Jacobson <angrybald...@gmail.com> wrote:
Surely if you're confident saying that the MySQL client library surely
has alternatives, you must have an example, no? Personally I find the
assertion somewhat surprising, since there is no market nor "itch" for
a third-party MySQL client library that I know of.
Clearly there's demand for a client library license-compatible with
closed-source development.
For MySQL? Forgive my blindness, but I see no such demand on the
market at large. Perhaps you could illustrate for me?
Keep in mind that due to the proprietary and unilateral nature of
database wire protocols, any MySQL-compatible driver would necessarily
either be MySQL-specific or contain a MySQL-specific protocol
adapter. The JDBC and ODBC models are such that the database vendor
provides exactly that adapter to fill in a standard API.
I do see a demand for closed-source-compatible database access,
certainly. That demand is well served by other players in the market,
such as PostgreSQL (open source; berkeley licensed) and SQL Server
Express Edition (closed source; different licensing structure from
MySQL) as well as others.
The marginal cost of [producing software] is obviously zero.
But the initial cost is not, and I hold that the initial cost of
reverse-engineering and redeveloping the MySQL client libs would never
be recovered by sales even when the marginal cost of each sale is
zero, because I see no viable market for a MySQL client library.
SQL itself is not proprietary; not patented/secret/whatever. Ergo,
someone will and probably someone has undercut MySQL's price for this
particular good.
Agreed, and examples abound. While the only third party to provide
MySQL client libraries has since been folded into MySQL and support
for the LGPL version dropped in favour of the commercial and GPL
versions, there is plenty of competition in the database arena. It's
not at the level of client libraries, though: it's at complete SQL
implementations.
MySQL's competition comes primarily from other database vendors:
Firebird, PostgreSQL, Oracle, and various others. Each (along with
MySQL) takes the SQL standard and provides its own "extensions", but
code that avoids those extensions allows different databases to be
dropped in exactly as you envision different client libraries being
dropped in.
While SQL the language is indeed a standard, there is no standard for
wire represntations of either queries or result sets
That's very odd. If there isn't, there certainly should be. That's as
if they'd standardized HTML without bothering to standardize HTTP.
Where is the business value in any database vendor changing their
product to conform to a third standard (after the SQL language and
JDBC/ODBC/$LANG db connector standards)? And how would a wire
protocol standard encompass non-network databases such as Hypersonic
and SQLLite which translate queries into function calls and structs?
Imposing a byte stream layer on those databases would seriously hinder
their primary benefit: speed.
There are also issues with the ancillary crud surrounding primary
purpose: not all databases have the same authorization and
authentication models, nor the same default behaviour in the absence
of an explicit transaction, nor the same implementations of the XA
APIs for distributed transactions, nor... a long list of things not
directly concerned with DDL or DML. Such a standard would have to do
one of two things: leave huge areas to vendors to specialize on,
making the standard effectively useless, or mandate one or a handful
of strategies for features that differ across vendors, which may not
be appropriate for all situations.
The database client development community and the database service
development community have already reached a good compromise between
feature flexibility and standardization at the API level. Why move
the standardization point when the existing situation is good enough?
And if someone did, would anyone follow?
Nevertheless, whatever protocol MySQL server uses is surely easy to
reverse engineer without "infecting" whatever you're developing with
the GPL, using the standard clean-room reverse engineering method used
to avoid copyright infringement when developing interoperable software
more generally.
Indeed, and if you believe there's a market for a clean-room
implementation of MySQL's wire protocols, and are willing to play
catch-up when MySQL AB unilaterally changes the protocol (as they are
wont to do), I encourage you to make one and sell it! Just because I
see no market doesn't mean it's not there, and capitalisim is built on
exploiting the shortsightedness of others.
You've repeatedly stated that someone could reverse-engineer MySQL's
protocol and server and add "extensions" to make their product more
competitive -- I ask this: what is the benefit in doing so as opposed
to creating a complete database implementation (client libraries and
all), and what are the risks inherent in doing so as opposed to
creating a complete database implementation?
Cheers,
Owen
[0] Anywhere in this post you could replace MySQL with any other
database and have the same post.