Ah, you have struck upon a nerve, the knee kicks up. If I were skilled
at finding old threads in our mailing list (which I'm not) I would show
you the discussion we'd be having on derby-dev about code sharing.
I will try to summarize, but I'm sure others will chime in:
* Currently the network client and the embedded driver and the
network server are all totally independent packages of code
(except for some shared constants)
* We have had numerous discussions about enabling more code sharing,
but it's trickier than you might think
* I think we are coalescing on making it a goal to incrementally
share more and more code. Two major areas: sharing the network
code between the embedded client and the network server, and
sharing the driver code between the embedded and network drivers.
Other areas include utility services that span these areas.
* Your participation in this effort would be most appreciated. So
far we haven't made much progress mostly because of lack of
resources (and also a lot of back and forth debate about exactly
how to do it).
Thanks,
David
Michael J. Segel wrote:
>On Wednesday 31 August 2005 10:49, Satheesh Bandaram wrote:
>
>
>> Thanks for the offer.. It would really be great to have more developpers
>>working on Derby. Join the derby-dev alias to participate in the
>>development.
>>
>> Derby embedded driver already has the capability to stream blob/clob,
>>without requiring reading them completely into memory. It would be great to
>>enhance Derby network server and Derby client to support this kind of
>>behavior.
>>
>> Satheesh
>>
>>
>>
>[SNIP]
>
>This may be a dumb question...
>
>Maybe its hindsight, but why isn't the Server Framework either a subclass or
>an extension to the embedded driver? Someone had posted that the Network
>Driver utilized the embedded driver... (Or is that bathtub gin affecting my
>memory?)
>
>I guess it goes more to the point of why not have more focus on a "universal"
>driver?
>
>
>
>
|