Hence, it does not allow for collaboration, running on a single PC. The use of a low level database has the advantage of speed, at the expense of being less known, and a lot more complicated to work with. However, genealogy data as stored by GRAMPS is a verly linked set of relations, so fitting it in a relational type of database is no easy feat.
Collaboration by exchanging your files in the gramps xml format is the way to go, but merging is not implemented yet, and even if added, people in the database world know that merging two diverging datasets back together is a very difficult task.
Now, people might opt for another solution, going for one of the collaboration apps out there for genealogy, some even open source. However, those work on GEDCOM, which is not as versatile as GRAMPS, so it means not using GRAMPS anymore. However, obviously one cannot always have the internet in it's pocket, so a collaboration app that could work in the data model of GRAMPS would be great.
It was hence with pleasure that I noticed that Django had reached version 1.0. This is important as
- Django is written in Python, so allows the use of GRAMPS code and logic directly. Present OSS collaboration apps for genealogy are in perl/php/...
- Django is a web application, so client-server is the way from the beginning
- Django interfaces with SQL databases (MySQL, PostgreSQL, ...)
- Write a model once, and without coding, administration code is available to edit the data via a web interface
With my web-design skills it is best to leave any web views to other developers, if there are any interested in that out there.
I know, why do what has been done again, blah, blah, join forces with other OSS efforts. You know, that is just not how it works. Anarchy rules? Perhaps. My take on it is that the tools we use improve, so there is a constant need to rewrite what has been done so as to use these new shiny tools instead. In this case, setting up a Django app is too difficult for most PC users (apache server configuration anyone?) so it will not replace GRAMPS in any way. That would actually be impossible anyway I think. However, thinking GRAMPS can 'evolve' so as to have an SQL backend or become client-server aware, is also wishfull thinking as there is just too much legacy to be carried. Better start a new initiative and see later on if there is possibility to work together. In the worst case, experience will be learned with what works, and what doesn't
More on the technical details some other time.