| [rt-pmc] Decision for Berkeley DB - Please add to Agenda |
|
Hi RT-PMC, could you please add a discussion over the
Berkeley DB CQ to the Agenda. https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2574 As discussed in
Last PMC call we need the ability to use Berkeley for a fixed timespan of at
most two years (I do not want to bother you several times in the PMC about it
therefore the duration). We would like to
use Berkeley DB as kind of OS dependency that is also used by Subversive in
their SVN connector. A link to the download: http://www.eclipse.org/subversive/downloads.php
We have several
reasons to use Berkeley DB: 1.
Currently no realistic
availability of a different XML Database that is scalable or at least reliable
(transaction support) that fits the Eclipse licensing policy 2.
Project plan needs some
constants to get a architecture running. a.
We need some XP to get a good
and performant interface declaration for a storage interface that is able to process
vast amount of information b.
Project need stability 3.
Berkeley DB is good and is
available as OSS 4.
Standard interfaces e.g. for
XQJ are not yet integrated in JDK 5.
Other Databases may currently
have side effects. E.g. could destroy XML document structure. From my point
of view there should be no problem in granting us the same right as the
subversive project for a defined timespan of two years. 1.
Standards will form and
therefore an abstraction will be more easy to be implemented 2.
IP should not be affected,
because in usage of a commercial or binary reference that has an OS character
should be no issue, because in case of libraries like MSVCRTXX.dll Eclipse
would never get the source code for IP and it still could be a required
dependency. Therefore a code check may not be required. 3.
We need a reliable working
database that allows us to check our architecture and its performance and functionality. 4.
We spent several weeks in
finding a realistic XML database that meets on high level the Eclipse licensing
requirements. The IP requirements are reducing the amount of available XML
databases to a minimum. Kind Regards, Georg |