David W. Van Couvering wrote: > Yes, I see what you're saying, you're rewriting JDBC extended with file > transfer. > > You could take the Derby source and extend it so that you can do file > transfer functionality, but then you're stuck with your own fork of > JDBC. And I'm sorry to say that the Derby community would likely not > accept your changes back (someone correct me if I'm wrong) because there > would be non-standard extensions to JDBC, and we strive to be > standards-compliant as a community.
I'm not so sure, some pluggable api that would allow additional communication over the same tcp/ip connection seems like an interesting direction. Innovation around open source. I think Oracle has some way of passing async events back to the client over the JDBC connection. > Personally, I would just open two connections: one for JDBC work and one > for file transfer. Keep them separate. That may be the simpler approach. Dan.
