-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ.fr
gramps-connect-desktop est la version autonome (voir
Installation). Un seul fichier regroupe le frontend de
app/ et le backend de gramps-web-api avec SQLite,
s'exécute entièrement sur votre propre machine, et n'écoute que sur
127.0.0.1 — rien n'est accessible via un réseau, et il a toujours
exactement un utilisateur fixé en dur (admin/admin). C'est fait
pour essayer Gramps Connect sur votre propre machine, pas pour partager
un arbre avec quelqu'un d'autre.
deploy/ est la véritable forme multi-utilisateur : un
app/ conteneurisé + backend gramps-web-api adossé à un véritable
Postgres, devant lequel se trouve Caddy pour le TLS, destiné à être
réellement hébergé quelque part — de vrais secrets, un vrai
domaine/certificat, et plusieurs utilisateurs ayant chacun leur propre
identifiant. C'est aussi le seul moyen de voir la collaboration en
direct en action — la version autonome est conçue pour un seul
utilisateur, il n'y a donc personne d'autre dont regarder apparaître
les modifications.
Plus proche que ne le suggère peut-être « déploiement basé sur
serveur » ci-dessus — les deux sont des applications mono-utilisateur,
strictement locales, construites sur la même base de données Gramps
sous-jacente. Aujourd'hui, Desktop est loin devant en fonctionnalités :
des décennies d'outils natifs, de gramplets, et de rapports que la
couche REST de gramps-web-api ne couvre pas (encore), ce n'est donc
pas un remplacement direct. Mais une interface plus rapide, basée sur
le navigateur, sur les mêmes données, est un vrai candidat pour
finalement rivaliser avec Desktop pour un usage quotidien.
Non. Il n'écoute que sur 127.0.0.1, la télémétrie est désactivée, et
tout ce qu'il stocke réside dans ~/.gramps-connect-desktop sur votre
propre machine. La seule exception, à activation volontaire, est
l'e-mail sortant (réinitialisation de mot de passe, etc.) — voir
Installation#configuration — qui est
désactivé sauf à le configurer délibérément.
Oui — Arbres généalogiques → Importer… accepte un fichier Gramps XML
(.gramps) ou GEDCOM (.ged), comme le vrai déploiement. Simplement
ne pas le traiter comme votre seule copie — garder une sauvegarde dans
tous les cas, comme il se doit pour tout outil encore en développement
actif.
Non — ~/.gramps-connect-desktop est séparé du binaire de
l'application, installer une version plus récente réutilise donc ce
qui est déjà là. Supprimer ce dossier vous-même pour repartir de zéro.
Oui, pour le déploiement serveur. Le backend dans
Déploiement est une instance gramps-web-api ordinaire et
non modifiée, gramps-project/gramps-web peut donc aussi y pointer —
mêmes données, mêmes arbres/utilisateurs, juste une interface
différente sur un port différent. Voir
Déploiement#running-gramps-web-alongside-gramps-connect
pour savoir comment configurer cela.
Gramps XML (.gramps) et GEDCOM (.ged) — les mêmes formats
qu'utilisent Gramps Desktop et gramps-web, un arbre peut donc circuler
librement entre les trois.
Oui — chaque onglet est un client indépendant du même backend
gramps-web-api (voir Architecture) ; les onglets ne
se parlent jamais entre eux et ne stockent pas non plus eux-mêmes vos
données d'arbre. Travailler sur des personnes, lieux, ou événements
différents dans des onglets différents est parfaitement sûr et ajoute
une charge négligeable — la seule activité en arrière-plan de chaque
onglet est la petite requête de la synchronisation en direct toutes
les quelques secondes (voir
Architecture#live-sync).
Deux choses rendent cela vraiment sûr, pas seulement « généralement correct » :
-
Le stockage est délimité de sorte que les onglets ne puissent pas
interférer. La connexion réside dans un
sessionStoragepropre à chaque onglet, chaque onglet démarre donc sa propre session (voir Sous le capot). La seule chose que les onglets partagent réellement, ce sont de petites préférences d'interface danslocalStorage(largeurs de colonnes, dernier nœud d'arbre déplié, …) — jamais des données généalogiques. -
Le seul vrai risque — modifier la même fiche dans deux onglets —
est intercepté avant de pouvoir causer des dégâts. Enregistrer une
Personne/un Événement/un Lieu/etc. est une écriture de l'objet
entier ; avant qu'elle ne parte, l'application récupère à nouveau
cette fiche et la compare à ce qu'il y avait quand elle a été ouverte
pour modification (
saveAll()deapp/src/store/draftStack.ts). Si elle a changé ailleurs entre-temps — un autre onglet, ou un autre utilisateur sur un serveur partagé — l'enregistrement est bloqué avec une erreur invitant à rouvrir la fiche, plutôt que d'écraser silencieusement qui a enregistré en premier.
La base de données SQLite de la version pour ordinateur est-elle sûre à utiliser depuis plusieurs onglets ?
Oui. Même si gramps-connect-desktop stocke l'arbre dans un seul fichier
SQLite, chaque onglet de navigateur parle à la même copie locale de
gramps-web-api, et ce serveur est délibérément configuré pour traiter
une seule requête à la fois (threaded=False dans
standalone/launcher.py), plutôt que plusieurs à la fois. Ce n'est pas
un goulot d'étranglement accidentel — il est là parce que le backend
SQLite de Gramps peut verrouiller définitivement la base de données si
deux requêtes atteignent close() en même temps (confirmé en direct :
un véritable import d'environ 10 000 objets suivi immédiatement d'un
rechargement de page l'a reproduit, et l'arbre ne s'en est jamais remis
sans tuer le processus). Sérialiser chaque requête à travers un seul
thread contourne complètement cette course, le fichier n'est donc
jamais touché par deux requêtes à la fois, peu importe le nombre
d'onglets ouverts.
Les discussions ont lieu sur le forum Discourse de Gramps ; les issues et pull requests contre le dépôt gramps-connect sont les bienvenues. Voir Développement.
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