Re: Some free utilities for Java, with Hebrew support.

On Sep 23, 12:48 pm, bbo...@xxxxxxxxx wrote:
On Sep 22, 10:09 pm, Owen Jacobson <angrybald...@xxxxxxxxx> 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.

.

Relevant Pages

  • Re: php/MySQL index filing?
    ... IDX type file that points to the record number in the main database, ... Some time ago I'd set up a standard php login routine and hit a brick wall as then found out that my host didn't allow external login's with MySQL so I got around it by writing a random access database with separate IDX files for username and passwords for cross-referencing. ...
    (comp.lang.php)
  • Re: MySQL not doing so well in Suns hands
    ... I debated this ad nauseum 10+ years ago when we were trying to get anything Informix on Linux. ... Unless there is momentum in the market for a product, ... The key is that MySQL _has_ a market, a very _entrenched_ market, with a solid, immovable developer base. ... the flexibility MySQL source code offers you is unparalleled in other database products. ...
    (comp.databases.informix)
  • Re: MySQL Database problem (probably already solved in a message, but this is somewhat urgent)
    ... MySQL server has a database with a table, ... columns, an FSR column, and a password column. ... checked if the supposed arrays that were returned were actually arrays ...
    (comp.lang.php)
  • RE: FreeBSD 5.3 MySQL Performance
    ... versions of Linux and FreeBSD for most tests. ... > popular with the ATA disk drive manufacturers. ... > Many companies have used FreeBSD and MySQL for years and years. ... it is not often that you have such a small database and such a large ...
    (freebsd-questions)
  • Re: GEDOM as a database format
    ... Tony Proctor wrote: ... isn't complicated Peter, but that doesn't make it impossible, and it doesn't ... It also includes the operating system crashing for no apparent reason and also the disk on which your database resides going up the swanee. ... The standard I want to see is something not constrained by application program, operating system, or hardware and even at a pinch be implementatble as a paper-based manual system. ...
    (soc.genealogy.computing)