-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ.de
🌐 English
gramps-connect-desktop ist die eigenständige Version (siehe
Installation). Eine Datei bündelt das Frontend von
app/ und das Backend von gramps-web-api zusammen mit
SQLite, läuft komplett auf dem eigenen Rechner und lauscht nur auf
127.0.0.1 — nichts davon ist über ein Netzwerk erreichbar, und es hat
immer genau einen fest eingebauten Benutzer (admin/admin). Es ist
dafür da, Gramps Connect auf dem eigenen Rechner auszuprobieren, nicht
um einen Stammbaum mit jemand anderem zu teilen.
deploy/ ist die echte Mehrbenutzer-Form: ein
containerisiertes app/ + gramps-web-api-Backend, unterlegt mit
echtem Postgres, vorgeschaltet mit Caddy für TLS, gedacht dafür,
wirklich irgendwo gehostet zu werden — echte Geheimnisse, eine echte
Domain/ein echtes Zertifikat und mehrere Benutzer mit jeweils eigenem
Login. Es ist außerdem der einzige Weg, Live-Zusammenarbeit in Aktion zu
sehen — die eigenständige Version ist absichtlich für einen einzelnen
Benutzer ausgelegt, es gibt dort also niemand sonst, dessen Änderungen
man beim Erscheinen zusehen könnte.
Näher dran, als „serverbasierte Bereitstellung“ oben vermuten lässt —
beide sind Einzelbenutzer-, rein lokale Apps, gebaut auf derselben
zugrunde liegenden Gramps-Datenbank. Heute ist Desktop bei der
Funktionalität weit voraus: Jahrzehnte an nativen Werkzeugen, Gramplets
und Berichten, die die REST-Schicht von gramps-web-api (noch) nicht
abdeckt, das ist also kein direkter Ersatz. Aber eine schnellere,
browserbasierte Oberfläche über denselben Daten ist ein echter Kandidat,
um Desktop für die tägliche Nutzung irgendwann Konkurrenz zu machen.
Nein. Es lauscht nur auf 127.0.0.1, Telemetrie ist deaktiviert, und
alles, was es speichert, liegt in ~/.gramps-connect-desktop auf dem
eigenen Rechner. Die eine Opt-in-Ausnahme ist ausgehende E-Mail
(Passwort zurücksetzen usw.) — siehe
Installation#configuration — die aus ist,
sofern sie nicht bewusst eingerichtet wird.
Ja — Stammbäume → Importieren … nimmt eine Gramps-XML-Datei
(.gramps) oder GEDCOM-Datei (.ged), genau wie die echte
Bereitstellung. Nur nicht als einzige Kopie behandeln — trotzdem ein
Backup aufbewahren, wie man es bei jedem Werkzeug tun sollte, das noch
aktiv weiterentwickelt wird.
Nein — ~/.gramps-connect-desktop ist getrennt von der App-Binärdatei,
eine neuere Version zu installieren verwendet also weiter, was bereits
da ist. Diesen Ordner selbst löschen, für einen wirklich sauberen Neustart.
Ja, für die Server-Bereitstellung. Das Backend in
Bereitstellung ist eine schlichte, unveränderte
gramps-web-api-Instanz, gramps-project/gramps-web kann also
ebenfalls darauf zeigen — dieselben Daten, dieselben Stammbäume/
Benutzer, nur eine andere Oberfläche auf einem anderen Port. Siehe
Bereitstellung#running-gramps-web-alongside-gramps-connect
dafür, wie man das einrichtet.
Gramps XML (.gramps) und GEDCOM (.ged) — dieselben Formate, die
Gramps Desktop und gramps-web verwenden, ein Stammbaum kann also frei
zwischen allen dreien wechseln.
Ja — jeder Tab ist ein unabhängiger Client desselben
gramps-web-api-Backends (siehe Architektur); Tabs
sprechen nie miteinander und speichern die Stammbaumdaten auch nicht
selbst. An unterschiedlichen Personen, Orten oder Ereignissen in
unterschiedlichen Tabs zu arbeiten, ist völlig sicher und verursacht
vernachlässigbare Last — die einzige Hintergrundaktivität jedes Tabs
ist die kleine Abfrage der Live-Synchronisierung alle paar Sekunden
(siehe Architektur#live-sync).
Zwei Dinge machen das wirklich sicher, nicht nur „meistens in Ordnung“:
-
Speicherung ist so abgegrenzt, dass Tabs sich nicht in die Quere
kommen können. Der Login lebt in tab-eigenem
sessionStorage, jeder Tab startet also seine eigene Sitzung (siehe Unter der Haube). Das Einzige, was Tabs sich teilen, sind kleinelocalStorage-Oberflächen-Einstellungen (Spaltenbreiten, zuletzt aufgeklappter Stammbaum-Knoten, …) — nie genealogische Daten. -
Das eine echte Risiko — denselben Datensatz in zwei Tabs zu
bearbeiten — wird abgefangen, bevor es Schaden anrichten kann. Eine
Person/ein Ereignis/ein Ort/usw. zu speichern ist ein Schreibvorgang
des ganzen Objekts; bevor er hinausgeht, ruft die App diesen
Datensatz erneut ab und vergleicht ihn mit dem Stand beim Öffnen zum
Bearbeiten (
saveAll()inapp/src/store/draftStack.ts). Hat er sich in der Zwischenzeit anderswo geändert — ein anderer Tab, oder eine andere Person auf einem geteilten Server —, wird das Speichern mit einem Fehler blockiert, der zum erneuten Öffnen auffordert, statt stillschweigend zu überschreiben, wer zuerst gespeichert hat.
Ja. Auch wenn gramps-connect-desktop den Stammbaum in einer einzigen
SQLite-Datei speichert, spricht jeder Browser-Tab mit ein und derselben
lokalen Kopie von gramps-web-api, und dieser Server ist bewusst so
konfiguriert, dass er jeweils nur eine Anfrage gleichzeitig bearbeitet
(threaded=False in standalone/launcher.py), statt mehrere auf
einmal. Das ist kein zufälliger Flaschenhals — er ist da, weil Gramps'
SQLite-Backend die Datenbank dauerhaft sperren kann, wenn zwei
Anfragen gleichzeitig close() treffen (live bestätigt: ein echter
Import von ~10.000 Objekten, direkt gefolgt von einem Neuladen der
Seite, reproduzierte es, und der Stammbaum erholte sich nie, ohne den
Prozess zu beenden). Jede Anfrage durch einen einzigen Thread zu
serialisieren, umgeht dieses Wettrennen vollständig, die Datei wird
also nie von zwei Anfragen gleichzeitig angefasst, egal wie viele Tabs
offen sind.
Diskussionen finden im Gramps-Discourse-Forum statt; Issues und Pull Requests gegen das gramps-connect-Repository sind willkommen. Siehe Entwicklung.
Gramps Connect is part of the family of Gramps-based software.
Using the app
- Overview
- Installing
- Deploying
- Messaging
- GOQL (advanced search)
- Gramplets & Add-on Store
- Data Model & Editing
- FAQ
Building & contributing