db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Planning for a 10.1 release
Date Wed, 25 May 2005 11:38:55 GMT
Daniel John Debrunner wrote:
> Jeremy Boynes wrote:
>>Andrew McIntyre wrote:
>>>I'm thinking that in the interests of getting an official release out
>>>with the Derby client, I'd like to aim for a release in about two
>>>weeks or so.
>>When we're ready - not before :-)
> I think we are ready, it would be good for Derby to get the open source
> client out as part of a release, release early release often!

I disagree. In this area alone:
* we have not made a decision on unification
* we voted to have the client driver match the embedded but
   functional differences remain

Early is one thing, premature is another.

>>>- Jeremy, in what timeframe do you think you will have a working
>>>prototype for the Datasource API changes? If you need help running
>>>tests against the prototype, please email me, I can help out with
>>>that. But, it's not clear to me that this is something that must be in
>>>the 10.1 release. Is this something that could be deferred to a 10.2
>>>(or even a 10.1.x) release? It's not unusual to manage API changes at
>>>release boundaries, so I don't think that having to support the
>>>current Datasource API going into the future is necessarily a reason
>>>to hold up this release.
> Also I don't think any decision has been made on if a unified data
> source api does make Derby easier to use.
> I'm still looking for a table of properties and how they apply to
> embedded or server mode. I think you keep pointing me to the prototype
> but your initial e-mail said it was missing some of the properties and
> the code I just looked at didn't seem to have all the client side
> properties.

The ones that are missing are:
* those related to trace
* resultSetHoldability
* retrieveMessageText
* securityMechanism

 From the user's perspective, all of these /should/ operate the same on 
both client and embedded and so I would contend are not distinguishing 
factors in this decision. We can either leave these undocumented for the 
current client or implement them in embedded in the future.

> The discussion is about having changing the api from
> ------------------------------------------------------------------------
> EmbeddedDataSource + embedded specific properties
> EmbeddedSimpleDataSource + embedded specific properties [needed for JSR 169]
> ClientDataSource + client specific properties
> ------------------------------------------------------------------------
> TO
> ------------------------------------------------------------------------
> UnifiedDataSource + complete set of embedded & client properties
> EmbeddedDataSource + embedded specific properties [possibly deprecated
> at some point]
> ------------------------------------------------------------------------
> While the UnifiedDataSource looks great when presented like that, the
> details are in the list of properties supported by the unified data
> source, and does the combined list end up being simpler or more
> confusing. I can see in the future more properties being added to
> support client side encryption, alternate transport, SSL client
> certificates, all ones that make no sense for embedded.

I think they do, specifically where we are embedded in a multi-user 
environment like an appserver. For example, a client side certificate, 
whilst applicable to SSL, could also be used in embedded authentication.

The difference is between traditional embedded mode where there was an 
implicit trust between application and database code, and multi-user 
scenarios where trust needs to be established for each connection or 

> Then beyond the api, there are possible technical issues with the client
> and embedded engine sharing code and ensuring that works in the future
> for different versions of client and embedded.

Those issues apply regardless of whether we unify or not. Unless we put 
client and embedded on different release cycles (which seems odd) they 
will be tested together, part of which will be need to be 
interoperability with older versions.

>>I still think introducing a major new API in this release with the
>>potential of it then changing incompatibly in the next one (especially
>>a dot release) is confusing.
> I think that's a little strong. The basic concept of the api is standard
> and the same in both cases, a class name and a set of Java Bean
> (DataSource) properties. And if 10.1 was released in its current form,
> three data sources, then it would not be changed incompatibly in the
> next release. A subsequent release that included a unified data source
> would be adding that option to Derby, with possible deprecation of other
> datasources in the future.
If we rush a release out now and unify later, users see:

10.1  new ClientDataSource and EmbeddedSimpleDataSource
10.x  new DerbyDataSource, deprecation of Client, EmbeddedSimple
       and Embedded

If x = 1.1 or 2 then what we did in 10.1 looks silly and, because it is 
a public API, we live with it forever (or a couple of years at least).


View raw message