There are 2 addons (that pop to mind) that sub-launch a LocalHost server service to power their person network graphing features. One requires no administration effort… it hides the server config entirely. The other puts the server hosting activation and port controls up front … as something to wade through before using the graph. They don’t share an approach. And probably use more resources as parallel approaches than a common server service would require.
The rationale is unclear (to me) for launching a LocalHost server as the springboard for their features. My terminology, understanding and assumptions are undoubtedly flawed but…
If a locally hosted, browser interface offers new opportunities, can your experiment make those competing approach unnecessary? And allow their browser interface frontends to use your localhost backend?
The existing localhost implementations seem to have flaws. So I am hoping your experiment will offer a more stable foundation and make their visualizations more accessible. And a consolidated LocalHost seems like it would be more resource efficient.
One localhost example hides the local host admin. But Przemek Więch’s Topola-based Interactive Family Tree localhost is more vulnerable to blind failures. (It offers no diagnostic leads.): @PeWu
The other (the one with the extra technical admin up front) is the Deep Connection Graph has connection-diagramming addon by Kari Kujansuu @kku. Some localization and display glitches can make this experimental Dashboard gramplet frustrating and the Person selection is painful… but provides “connection network” visualization value that cannot be found elsewhere. And I have not seen other contributors developing “node-network” visualizations. (The Gramps export GEDCOM to yEd import visualization of family nodes is excellent. But the workflow is too complex for most users.)
I do not know if this is related. But another feature that has stagnated for years and is severely under-documented is the database Host/Port setup, found in the Database Location portion of the Family Tree tab of Preferences. It supposedly works in some OSes. But I do not recall anyone ever reporting success with it. That is probably why the wiki only has 2 sentences about it.
Thanks for the question @emyoulation. Your question dives into some technical layers, but I’ll try to keep it abstract.
First, I must admit that I hadn’t ever looked at the two addons you mentioned (Topola Interactive Family Tree, and Deep Connections Graph (not in Gramps’ standard addons)). Both work in similar ways:
A local webserver is started
Allows Gramps desktop to talk to it
You use the name “localhost” to refer to them, but that is just a special name for a internet address for a server running on your own computer. The category could better be described perhaps as “webserver-based applications”.
It is an interesting idea to extend Gramps to allow interactions with such webservers. But as you noted, the connection could be fragile, and subject to OS security issues. That is the nature of this type of gramps → webserver interaction.
Now how does that relate to gramps-connect? It doesn’t directly, but it is a bit related to gramps-web-api. This is the webserver (sometimes called the “backend”) behind gramps-web and gramps-connect. The gramps-web-api server can also be accessible via “localhost”. But it was properly designed to be a production webserver on the internet. That involves many issues like security and authorization, prevention of denial of services attacks, fast responses, and more.
So, to your main question: does gramps-web-api have anything to help with other webservers, localhost or not? Not that I see. But there may be connections the other way round: these webserver addons suggest ideas for gramps-web-api based applications, like gramps-connect and gramps-web.
I’ll describe the relationship between these components in another post.
Oh, and a comment about the databases accessible via username and password. This are databases (such as postgresql) that live on the internet via a webserver. This type of interaction is made possible by the abstractions in our database layer in Gramps (so-called DB-API).
The postgresql database could have a localhost connect (eg, live on your computer). But is much more useful on the internet where you can collaborate with others in the same database. But there are some issues (such as how you deal with two people editing the same object).
In my opinion, this type of arrangement (connecting gramps desktop to a postgresql server) is useful today, but will be superseded by the new addon GrampsWebApiDb (soon to be completed for Gramps 6.0). Instead of having gramps desktop talk directly to the internet database, you talk to the gramps-web-api server. I’ll describe this project in another post.