db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: derby standards
Date Thu, 25 Aug 2005 22:20:40 GMT
David Van Couvering wrote:

> I do want to make one point. In my opinion, the DRDA communication
> between client and server is purely an internal interface. It is not
> touched by our users and changing the underlying protocol would in no
> way impact the portability of applications written in Derby to other
> databases.  I think in the past the value of using DRDA is it allows the
> IBM unversal driver to work with Derby; when Derby was an internal DB at
> IBM this made a lot of sense.  My question is is this still a
> requirement for Derby as an Apache project?  At this point, I see no
> compelling reason to move away from DRDA, but if at some point it
> becomes clear it really is hamstringing us in some way, either in terms
> of performance, security or functionality, I'd like to understand where
> we as a community stand on this question.  Do we try to convince the
> Open Group to change DRDA every time we have an issue, or do we forge
> ahead with our own modifications even if they're non-standard?

In a way DRDA is an api into Derby. Derby's use of a standard protocol
allows third parties to write clients that connect to Derby. There are
two concrete examples of these, IBM's JDBC and ODBC drivers. Now I agree
that those exist due to Derby's history, but there are other companies
out there that write such clients.

Totally throwing out DRDA seems to be a bad idea because we have to
replace it with something, and why define a new database protocol when
one exists already. Adopting another could be a possibility, I looked at
Sybase's TDS given the OpenTDS project but since that is reverse
engineering and has lots of cases like 'byte[4] no idea what goes here'
it didn't seem attractive to me.

It seems unlikely that DRDA will not be sufficient for our performance
needs, DB2 reguarly holds the top spots in TPC-C and other benchmarks,
so DRDA seems to be up to the task.

I agree its functionality it may fall short, but Rick's current approach
seems great, carefully define how we want to expand it, document it and
try to get it into the OpenGroup.


View raw message