I think the ClientBaseDataSource was not meant to be a public class. We tried to localize all public classes into the 'jdbc' package and use only the jdbc package to generate public javadoc. That is one of the reasons for putting all public tracing support in ClientDataSource.
I would also like to match API with Embedded driver as much as possible. It would be real bad if applications need changes when using two different driver offerings of Derby. Your suggestions probably don't break this, but something to watch for. We tried to match Embedded behavior, unless it was deemed WRONG.
I agree that we want to the two to match up. Right now there are differences e.g. in where methods are declared, what the properties are and so forth. We should bring these into line.
In the embedded case, the base class is ReferenceableDataSource which is in the public API package (jdbc). By that argument moving the properties into ClientBaseDataSource is improving alignment and the next phase should be to move it into the jdbc package in the client tree.
This does raise the question of whether there should just be one implementation of the public API shared by client and embedded code, just with different implementations behind it. Ultimately I would like to get there.
-- Jeremy
