db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: derby standards
Date Fri, 26 Aug 2005 00:07:25 GMT
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.


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.

View raw message