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
operation.
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).
--
Jeremy
