Thanks again John. I find dialog like this very helpful. I too am not
an expert but have talked to a lot of people who use Derby. It is very
possible, however, that the perceptions I have gotten are not the norm
so I appreciate questions and suggestions like you have posed.
Responses to a few specific points interspersed:
John Embretsen wrote:
[SNIP]
Perhaps it is better to encourage people try it out, than to scare
them off with warnings of what _might_ happen if they do this and
that. Of course, users who (willingly or accidentally) double-boot a
database risk corrupting their data, but the manuals have that covered.
I am feeling fairly comfortable with the changes implemented in Derby to
prevent double-booting when using v 1.4 and higher JVMs. It is
certainly much harder to perform a double-boot now than when v 1.3 JVMs
were in common use. This is why I did not emphasis the issue in the WWD
document.
[SNIP]
Yes, I think a document explaining the basics (and more) of the
different architectures/frameworks would be useful, and better than
including it all in the WWD document. Most of it is covered in the
manuals, the web tutorial or elsewhere, but I miss a document where
all the different embedded/client/server configurations are discussed
and compared, such as:
a) Pure embedded Derby
b) Derby client/server, including:
b.1) Derby "stand-alone" server framework
b.2) Derby "embedded server" framework
b.2.1) Managing the embedded server using the API
b.2.2) Managing the embedded server using system properties and
the embedded driver
b.2.3) Accessing Derby in this configuration using the embedded
driver
b.2.4) Accessing Derby in this configuration using the client driver
[SNIP]
I have saved this list and will try to address most, if not all, these
issues in the document I referred to earlier
