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: Planning for a 10.1 release
Date Wed, 25 May 2005 04:03:29 GMT
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!

>> - 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

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


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.

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.

> 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.


View raw message