Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Arno Welzel Newsgroups: de.comp.lang.javascript Subject: =?UTF-8?Q?Re=3a_Aktion_beim_Schlie=c3=9fne_eines_Browserfensters?= Date: Fri, 14 Dec 2018 11:34:39 +0100 Lines: 35 Message-ID: References: <8ec1baef-ed6d-aad5-73df-b7c9dedfb099@PointedEars.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: individual.net XcbPM3wIW8U7ELNPeaOZ+QH5heYgQavxSj+uCGbyiFomS4vsUm Cancel-Lock: sha1:YJieMxmvW218ERcgZxwFOyPl0jM= Openpgp: preference=signencrypt In-Reply-To: Xref: csiph.com de.comp.lang.javascript:5001 Arno Welzel: > Peter J. Holzer: > >> On 2018-12-07 20:17, Arno Welzel wrote: > > [Locking von Dokumenten bei Bearbeitung] >>> Was wäre denn die "richtige" Lösung? >> >> Im konkreten Fall? >> >> Auf das exklusive Sperren verzichten und entweder ein Three-Way-Merge > > Ein Merge kann aber nicht auflösbare Konflikte verursachen, die man dann > als Benutzer klären muss. > >> oder eine "Live"-Bearbeitung (a la Etherpad, Google Docs, etc.) >> implementieren. Aus Benutzersicht jedenfalls. Aus Entwicklersicht mag >> das angesichts dräuender Deadlines anders aussehen. > > Auch aus Benutzersicht mag es auch wenig sinnvoll sein, ein Dokument > permanent bei jeder Eingabe zu ändern, wenn man das versionieren will. > Ja, mir ist bekannt, dass Etherpad einzelne Änderung in seine Datenbank > schreibt. Das ist aber wenig hilfreich, wenn man z.B. von einem Artikel > einen Stand vor und nach einer redaktionellen Überarbeitung braucht. Ingrid weist mich auch noch auf den Widersprich hin, wieso "alle 30 Sekunden Server kontaktieren, damit die Session nicht ausläuft" falsch ist, aber "jede Änderung sofort zum Server schicken" dann "richtig" sein soll. -- Arno Welzel https://arnowelzel.de