Others here at Sun have mentioned the same point to me, it allows for
third-party clients. So I withdraw my claim that it is not a
"published" API.
David
Daniel John Debrunner wrote:
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.
Dan.
begin:vcard
fn:David Van Couvering
n:Van Couvering;David
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
