Gramps Web is not an addon... so what is it?

Gramps Web is currently filed on the Wiki in an “Addon” category but that is not accurate.

By convention, we have every addon’s wiki page title with an “Addon:” prefix. What other Naming Convention can we use to prefix such independent projects that use either the Gramps Engine or Gramps format data

The Gramps Web Sync is an addon tool available in the main project Addon repository and also in David’s Repository. But Gramps Web is something else. (Just like Betty and PhpGedView.)

The Gramps Web describes it as interoperable with Gramps.

  • interoperable
  • compatible
  • Cross-compatible
  • Cross-platform
  • external
  • Interconnective

I would say it is an install on par with the Windows’ AIO or Mac’s dmg installs It is installing Gramps in an environment.

The major difference with it and the AIO or Mac installers, it is not created from within the Gramps-project.

Deciding whether a listing belongs in the Downloads can wait a bit. Right now, let’s discuss how to name wikipages for such software.

Gramps Web is young enough that there will probably be a good bit of evolution as the Installer matures.

Gramps Web is not an independent project.

It consists of two components: a RESTful API that provides access to Gramps family trees and a web front-end. From a user perspective, it’s probably just another front-end much like the GUI and command line interface.

I also note that the wiki page describes Gramps Web as “a separate project based on the same code base as Gramps Desktop.” This is not particularly helpful. I can see where the confusion may arise though. Gramps Web has a separate web site for it’s documentation, uses a different bug reporting system, and communications such as release announcements are not made on the mailing lists or blog.

Perhaps we need to think about how we can better integrate Gramps Web into our ecosystem? @bmatherly Do you have any views on this?


Yes, I think that’s a good way to put it.

… and for those note so familiar with it, technically it has three components, the third component being the Gramps Python library itself. I think that’s what’s meant in the Wiki by “same code base”, but I agree this Wiki article could use some rewriting.


Does “Gramps engine” resonate as a coined phrase for the Gramps Python library?

OK, but it should be docker independant.
We must be able to install it on nginx, apache, IIS… with a good documentation.

1 Like

Are changes for 5.3 needed to the Plug-in Registration (on Sphinx) for Gramps-Web?

The reports have:

Does there need to be a Gramps Plugin Registration option for Gramps Web so that it will be able to use the Addon Manager? And does it need to be recognized as the current GUI by the cli module?

@DavidMStraub Can Gramps Web currently use CLI commands for Reports with REPORT_MODE_CLI compatibility?

I would answer “no” to all of these questions. I don’t think it makes sense treating Gramps Web (or even Gramps Web API) as a plug-in in the current framework. I also don’t see the benefit.

When it comes to better integrating Gramps Web [API] into the Gramps ecosystem, what I would rather be thinking about is moving some of the code from the gramps_webapi Python module into the gramps library. But that would only make sense if the Gramps library had a (much) shorter release cycle and stricter Python version requirements. And I understand why this is problematic from a Gramps [desktop] point of view.

From a user perspective, I think what matters is integration with addons, and there I think the situation is not so bad:

  • Gramps Web Sync addon
  • Shared PostgreSQL database addon
  • S3 Media Uploader addon

I wasn’t suggesting making Gramps Web into a plug‐in. I was talking about making plug‐ins have a way to register that they are also compatible with Gramps Web… or ONLY compatible with Gramps Web!

If the idea is to give Gramps Web parity with the Gtk GUI or the CLI frontends, then it probably needs a way to identify plug-in (both for the built-in and add-on) compatibility in the same system.

It might be reasonable to consider that someone might want to extend into an alternate GUI frontend… like Qt … for a mobile device frontend.

Or, down the line, some interface toolkit for a VR frontend.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.