Difference between revisions of "GEPS 013: Gramps Webapp"

From Gramps
Jump to: navigation, search
(TODO)
(Django)
Line 64: Line 64:
 
# Checkout the branches/geps/gep-013-server from SVN
 
# Checkout the branches/geps/gep-013-server from SVN
 
# cd gep-013-server/webapp/gramps
 
# cd gep-013-server/webapp/gramps
# Edit last 2 lines in settings.py to point to your source of GRAMPS, and a database name
+
# Edit the path to the Sqlite DB and the last 2 lines in settings.py to point to your source of GRAMPS, and a database name
 
# make
 
# make
 
# make run
 
# make run

Revision as of 04:17, 10 August 2009

Proposition of a GRAMPS Web Application. Now that the main graphical user interface (GUI) has been separated from the command-line interface (CLI), a web application would be the next logical step.

Motivation

Web developers are in need of a method of accessing and creating functionality with their GRAMPS data on the web. Having a GRAMPS webapp would allow a GRAMPS-based web project.

Here is a small list of goals:

  1. Create a fullscale GRAMPS web framework
  2. Allow multiple users via the standard web browser
  3. Build on GRAMPS codebase and wealth of resources
  4. Use standards and well-known, well-tested frameworks where possible
    1. Consider the WSGI protocol
    2. Consider Django, ZOPE, and other frameworks
    3. Consider the data access

Example GMS Web Sites

Genealogy Management Systems on the web:

Discussion

Many of these comments were directed at an earlier prototype on a GRAMPS Server Mode‎. This GEP has been updated to reflect the larger goal of building a fullscale web application.

Richard Taylor noted:

  • I think that you need to think very carefully about the use of the Threads in the server model. I don't think that database backend if thread safe and strange things might happen. (I have not looked at the database for about 3 years, so things might have changed). You might think about a async server approach using something like twisted.
  • The use of eval to execute the client instructions is very unsafe from a security point of very. If you are going to use this model you should restrict connections to those from localhost or use only unix domain sockets or think about strong authentication.

Brian Matherly noted:

  • I think the RPC strategy should be XML based. In particular, it makes sense to me for the Gramps "server" to be Web Services based. We should look at something standard like SOAP. That will make it most friendly for clients to access and opens a whole world of unimagined possibilities in the future for mashups.
  • If the Gramps project is eventually expanded to include a "web server"/ "web app"/"web services" aspect, I strongly believe that it should be done as a separate application. In fact, the end goal should probably be for a multi-part repository of code that includes: A GTK based desktop application, a CLI only application with much fewer dependencies, a web server application that provides a web service, a web server application that serves actual web pages (real time NavWeb), and one or more core libraries to support these applications in a well thought-out, abstract and maintainable manor.
  • In order to archive the goals I listed in #2, we first need agreement from the developers that we want to go that direction. If we achieve that, we need an architectural plan that can bring us there. If not, we should branch this idea off as a separate project on SF.

Benny Malengier noted:

  • BSDDB has a multiuser flag (which is not switched on), to allow for things like this.
  • Goal 1 should be a definition of how a server can work on bsddb using present src/gen, how request from a client can be done, and how replies should be structured (I would hope our own xml schema). Then some framework to do the client itself, so as not to reinvent the wheel.
  • Goal 2 a barebones client: a listview of all primary objects (shown per 25/50/100 entries ), and html editor for the main info of the primary objects.
  • Thoughts about breaking GRAMPS into parts
  • For a server part I would restrict to a linux server strictly now.

TODO

  • Develop a SQL Export for GRAMPS. DONE. See GRAMPS SQL Database
  • GRAMPS currently needs a display. I had to make some changes in GRAMPS that I haven't committed yet that allows GRAMPS to run without having X or a display. But you won't notice this issue when you run the code if you have a display---the issues only shows up when trying to run without one.
  • Explore Web frameworks. In progess, below.

Web App Architecture

There were many good ideas on the talk page and in the mailing list about the functionality of the webapp. A couple of them involved the security of the site.

An idea that emerged is to allow access to non-logged in users, but only show the data via a private proxy. That way, a visitor (and google) can see things like "Living Smith". However, as you log in, you gain ability to see detail, and edit the data.

Django

A prototype of a GRAMPS Django webapp is in branches/geps/gep-013-server. To run it, do the following:

  1. Download Django. I'm running version 1.0.3
  2. Checkout the branches/geps/gep-013-server from SVN
  3. cd gep-013-server/webapp/gramps
  4. Edit the path to the Sqlite DB and the last 2 lines in settings.py to point to your source of GRAMPS, and a database name
  5. make
  6. make run
  7. Point your webbrowser to:
    1. http://127.0.0.1:8000/
    2. http://127.0.0.1:8000/admin/

Django-home.png Django-details.png Django-admin.png