From: Bret B. <br...@bu...> - 2003-11-12 02:25:07
|
On Tue, 11 Nov 2003, Don Allingham wrote: > > In the Open Source world, there are more options. We have the option of > using > a full blown SQL database (such as MySQL or PostgreSQL), a lighter SQL > database, > (SQLite), or an embedded database (Berkeley DB). > <snip> > > My current thinking is to allow different backends. I think I have a way > of doing this > without causing too many headaches in the development process. I would > like to try > keep the XML backed as a low end option. > > The goal is to provide a base DB that offers a high level of > functionality without any > installation pain. I'm leaning towards using the Berkeley DB, which is > built into > python. By using this, we can address the needs of about 95% of the > users without > any installation effort. > > Granted, the basic database will be the first priority, since that is > what most users > will use. And even if we don't keep the XML backend, we will still be > able to import > and export to the XML format. My suggestion, in consideration of all of the above, is the following, in sequence and order of priority. 1. Keep the XML backend. Whatever else happens, that is fully portable, and, there is always the chance that the GEDCOM standard may be modified (from its principly (as in similar principles to) XML style format), to a fully XML implementation, to which it should not be difficult to port the GRAMPS XML format, or, to translate GRAMPS XML on the fly. Similarly, keep the GEDCOM import/export, and maintain its compliance with GEDCOM standard. Perhaps, Don could interact with the Mormon Church people who are responsible for the GEDCOM standard, to seek a revision, to transform the GEDCOM standard, to a pure XML format, which could be used directly by GRAMPS (replacing the current GRAMPS XML format) and other genealogy software, as well as non-genealogy software. 2. Incorporate (in a future version) the embedded SQL database Berkeley DB. From what has been said, that requires no extra user actions to have the SQL functionality and the power of an SQL database; thus, it should cater for, and encourage users who are not so computer literate as to be able to instal and configure more heavyweight SQL databases, such as PostgreSQL and MySQL, yet give them the added power and functionality of an SQL database incorporation into GRAMPS. That could also allow SQL programmers, to develop their own reports, etc, which may facilitate inclusion of the reports into later, expanded versions of GRAMPS, facilitating more open source development of GRAMPS, and, getting more GRAMPS developers, on a "de facto" basis. 3. At some later time (further future version), investigate, and, if feasible and practical, implement catering for more heavyweight SQL database backends, such as PostgreSQL and MySQL, with option for user to choose which backend, so that, on installing that version (and later versions) of GRAMPS, user is given the options "Do you want to use a database other than the embedded database for your installation of GRAMPS <yes/no> (if yes, then) Select database backend <*> PostgreSQL < > MySQL < > Oracle < > SQLite (etc)" with GRAMPS having, in the installation process, the consequential choosing by the software, of the DBI/ODBC interface of the particular SQL database backend, installed as part of the installation process, leaving it up to the user to install the appropriate database backend, and to ensure that that database backend is configured and running okay. 3(a) Alternatively to 3 above, develop and provide modules for specific database backends, which can be separately downloaded and installed, to hook into GRAMPS and interface with each particular database backend, leaving the installation and configuration work, to the user (with whatever guidelines/instructions are necessary, that are specific to the GRAMPS module). 3 and 3a above, could be allocated/delegated to developers who develop in the specific areas of the DBI/ODBC interfacing of the particular database backends, to keep the existing (and future) GRAMPS developers, free to concentrate on GRAMPS internal functionality. If 3a is used, revision of the modules, as GRAMPS, and as the databse backends, are each updated and modified, could be made easier, by leaving the revisions to the DBI/ODBC specialists, leaving the GRAMPS developers, to concentrate on GRAMPS development. I believe that such a path would be best for everyone, and, modularise the interfacing with the SQL database backends, and should please as many people as possible, from the relatively computer illiterate, to the database gurus (who may be able to assist in developing the database interfacing). Those are my thoughts - I hope they are helpful. -- Bret Busby Armadale West Australia .............. "So once you do know what the question actually is, you'll know what the answer means." - Deep Thought, Chapter 28 of "The Hitchhiker's Guide to the Galaxy: A Trilogy In Four Parts", written by Douglas Adams, published by Pan Books, 1992 .................................................... |