Well, there's three different things: a) Get away from the current "two-dotted" extension, since many SDKs cannot handle that. b) Make the extension configurable. c) Do away with the extension altogether (and, conceivably, use the file header for identifying H2 files).
Of those options the first one is probably easy to implement and wouldn't impede changing to one of the other options later on. However, it does break backwards compatibility, because the newer H2 engines won't recognize the old extensions anymore, unless some ugly workaround code is introduced. Therefore I tend to prefer the second option, because it would allow restoring backwards compatibility - the user could simply configure .h2.db again. I am not sure where this file extension is being used in the codebase, perhaps it is relatively unimportant internally? In that case it would be enough to just stop adding the .h2.db extension to every database url. Users wanting to keep the old .h2.db extension or using a new one would simply have to change their JDBC urls to reflect that. So that would be another option: d) Stop adding extensions to JDBC urls altogether. Ulrich -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To post to this group, send email to h2-datab...@googlegroups.com. To unsubscribe from this group, send email to h2-database+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
