I would rather see the current derby project concentrate on the
engine and not have tools included in it's charter. It would be
great to see a separate
project formed for those interested in derby based tools such
as this and others. Then this could go through the proper
incubation/legal steps. Sort of how lucene is set up with a
base core project and multiple other projects that are built
on top of the base project.
This new project might also be a good place for database extensions that
are now possible and those that may be enabled in the future. For
instance I think sharing table function implementations could be
valuable. This might also be a place to collect libraries of user
defined functions usable in derby - I think one such set suggested in
the past was those implementing spatial capabilities.
Dag H. Wanvik wrote:
Rick Hillegas <[EMAIL PROTECTED]> writes:
Derby may be the wrong place for your tool itself, however. I don't
want to discourage you but it seems to me that the Derby charter
pointedly excludes "Database GUI tooling":
http://db.apache.org/derby/derby_charter.html#Database+Technology I
hope that someone will correct me here if I am mis-interpreting that
part of our charter. I don't know why the charter excludes GUI
tools. I suppose the community could consider changing that clause.
When I read this wording I get the idea that the intention here is
exclude general database tools, e.f. for constructing SQL queries
based on existing tables etc. I am not sure the intention was to
exclude a dedicated tool to administer Derby? But I can see it is at
least arguable that exclusion is intended. Note that a command line
based management tool would not be excluded...
What would it take to change to charter wording to allow an
administration tool for Derby?
I think it would benefit Derby to make the threshold as low as
possible for people wanting to contribute in this area, by allowing
this to coexist with Derby.
Dag
