Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.lang.javascript > #4984 > unrolled thread

Aktion beim Schließne eines Browserfensters

Back to article view | Back to de.comp.lang.javascript

Contents

  Aktion beim Schließne eines Browserfensters Ralph Stahl <post@rstahl.de> - 2018-12-05 14:37 +0100
    Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-05 22:35 +0100
      Re: Aktion beim Schließne eines Browserfensters Ralph Stahl <post@rstahl.de> - 2018-12-06 14:24 +0100
        Re: Aktion beim Schließne eines Browserfensters "Christoph M. Becker" <cmbecker69@arcor.de> - 2018-12-06 15:35 +0100
        Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-06 17:21 +0100
        Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-06 18:57 +0100
          Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-06 21:22 +0100
            Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-07 19:47 +0100
              Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-07 20:22 +0100
                Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-07 21:17 +0100
                  Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-14 00:03 +0100
                    Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-14 11:33 +0100
                      Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-14 11:34 +0100
                        Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-16 21:22 +0100
                          Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-17 13:25 +0100
                            Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-20 13:32 +0100
                              Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-22 11:56 +0100
                                Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2019-01-02 13:22 +0100
                                  Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2019-01-03 08:50 +0100
                    Re: Aktion beim Schließne eines Browserfensters Stefan Reuther <stefan.news@arcor.de> - 2018-12-14 18:56 +0100
                      Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-15 12:48 +0100
                      Re: Aktion beim Schließne eines Browserfensters "Peter J. Holzer" <hjp-usenet3@hjp.at> - 2018-12-16 21:43 +0100
                Re: Aktion beim Schließne eines Browserfensters Jan Novak <repcom@gmail.com> - 2018-12-10 10:02 +0100
                  Re: Aktion beim Schließne eines Browserfensters Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-12-10 21:26 +0100
      Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-07 21:09 +0100
    Re: Aktion beim Schließne eines Browserfensters Arno Welzel <usenet@arnowelzel.de> - 2018-12-07 21:13 +0100
      Re: Aktion beim Schließne eines Browserfensters Ralph Stahl <post@rstahl.de> - 2018-12-10 10:46 +0100

Page 1 of 2  [1] 2  Next page →

#4984 — Aktion beim Schließne eines Browserfensters

Moin!

Ich möchte erreichen, dass beim Schließen eines Browserfensters über das 
Kreuzchen rechts oben als letzte Amtshandlung die im Browser laufende 
Anwendung noch ordentlich geschlossen wird (Session schließen etc). Nach 
zum Beispiel [1] sollte das durch das Abfangen des onunload-Events 
passieren können. Mir schwebt vor, das so ähnlich zu tun:

$(document).ready(function () {

     window.unload = function () {
         $.post('funktion.php');
     };
     ...
}

In funktion.php soll soll u.a. protokolliert werden, dass ich hier 
"vorbei gekommen" bin (das ist erprobt). Aber es passiert nichts. Auch 
nicht mit onbeforeunload nach [2].

Ein anderes Beispiel fand ich bei stackoverflow [3], ich habs etwas 
abgewandelt, aber das tut auch nichts:

<html>
<body>
     <script>

         function goodBye(evt) {
             console.log('unload');
             return 'good bye';
         }

         window.onbeforeunload = goodBye;
	
     </script>
</body>
</html>

Warum bewirkt das alles nichts?

Nun habe ich allerdings auch ein technisches Verständnisproblem. Wie 
funktioniert es, dass ein Browser-Tab oder das ganze Fenster (was ja vom 
System dargestellt wird!) noch etwas tun kann, sobald es abgeschossen 
wird oder sogar (im zweiten Fall) sobald es *gleich* abgeschossen werden 
wird? Ist das nicht á la Münchhausen? Ich könnte ja im ersten Beispiel 
auch statt $.post() einfach alert('huhu') schreiben - aber wer soll das 
darstellen, wenn das Fenster zu geht oder schon zu ist?

Ich würde mich sehr über Hinweise freuen. Ehrlich gesagt weiß ich nicht 
so recht, wie ich Frau Goggel gezielter fragen soll...

Ralph



[1] https://www.w3schools.com/jsref/event_onunload.asp
[2] https://www.w3schools.com/jsref/event_onbeforeunload.asp
[3] https://stackoverflow.com/a/16924095/9776286

[toc] | [next] | [standalone]

#4985

Ralph Stahl wrote:
> Ich möchte erreichen, dass beim Schließen eines Browserfensters über das 
> Kreuzchen rechts oben als letzte Amtshandlung die im Browser laufende 
> Anwendung noch ordentlich geschlossen wird (Session schließen etc). Nach 
> zum Beispiel [1] sollte das durch das Abfangen des onunload-Events 
> passieren können. Mir schwebt vor, das so ähnlich zu tun:
> 
> $(document).ready(function () {
> 
>      window.unload = function () {
>          $.post('funktion.php');
>      };
>      ...
> }
> 
> In funktion.php soll soll u.a. protokolliert werden, dass ich hier 
> "vorbei gekommen" bin (das ist erprobt). Aber es passiert nichts. Auch 
> nicht mit onbeforeunload nach [2].
> 
> Ein anderes Beispiel fand ich bei stackoverflow [3], ich habs etwas 
> abgewandelt, aber das tut auch nichts:
> 
> <html>
> <body>
>      <script>
> 
>          function goodBye(evt) {
>              console.log('unload');
>              return 'good bye';
>          }
> 
>          window.onbeforeunload = goodBye;
> 	
>      </script>
> </body>
> </html>
> 
> Warum bewirkt das alles nichts?

1. <http://glasgoogle.de/> (leider ist unsere FAQ etwas angestaubt)

2. Das ist kein gültiges HTML(5): <http://validator.w3.org/>

3. Du schreibst auch nicht, mit welchem/-n Umgebungen Du getestet hast.

Vermutlich geht es zumindest teilweise nicht zum Schutz des Benutzers (was
zeigt die Fehlerkonsole?).  Wäre das nämlich möglich, was Du willst, dann
könnte jede Website, ohne dass der Benutzer das beeinflussen kann, beim
Wegnavigieren noch schnell irgendwelche Daten absenden, und der Benutzer
müsste warten, bis das geschehen wäre (oder definitiv fehlschlüge).

Diese beiden Events (“unload” und “beforeunload”) werden nämlich nicht nur
gefeuert, wenn das Browserfenster bzw. der Browser-Tab geschlossen wird.

Dass in unload- und beforeunload-Listenern nicht alles funktioniert, ist
bekannt.  Besonders in Firefox sind hier zum Schutz des Benutzers die
Möglichkeiten für Webentwickler stark eingeschränkt.  Was sicher geht ist
das Gezeigte: im onbeforeunload-Listener einen String zurückgeben, mit dem
der Benutzer gefragt werden kann, ob er wirklich wegnavigieren will.

Beim unload-Event ist es eventuell auch schon zu spät, weil relevante
Objekte schon nicht mehr verfügbar sind oder währenddessen abgeräumt werden.
 In jedem Fall ist es eine Race Condition.

<https://javascript.info/onload-ondomcontentloaded>

Sessions lässt man am besten bei Logout oder mit Timeout expiren
(Session-Cookies und Server-Sessions), da man sich nicht darauf verlassen
kann, dass clientseitiges Scripting verwendet wird.

Übrigens ist jQuery hierfür Overkill; daher das einfache Beispiel auf
Stack Overflow.

> [1] https://www.w3schools.com/jsref/event_onunload.asp
> [2] https://www.w3schools.com/jsref/event_onbeforeunload.asp

*Alle* Bookmarks mit URI-Präfix “https://www.w3schools.com/”
*löschen* und ersetzen durch die äquivalenten mit Präfix
<https://developer.mozilla.org/>.

JETZT.  SOFORT.

<https://www.w3fools.com/>

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4986

Das Problem ist bereits gelöst, siehe unten.

Thomas 'PointedEars' Lahn schrieb:
> Ralph Stahl wrote:
>> Ich möchte erreichen, dass beim Schließen eines Browserfensters über das
>> Kreuzchen rechts oben als letzte Amtshandlung die im Browser laufende
>> Anwendung noch ordentlich geschlossen wird (Session schließen etc). Nach
>> zum Beispiel [1] sollte das durch das Abfangen des onunload-Events
>> passieren können. Mir schwebt vor, das so ähnlich zu tun:
>>
>> $(document).ready(function () {
>>
>>       window.unload = function () {
>>           $.post('funktion.php');
>>       };
>>       ...
>> }
>>
>> In funktion.php soll soll u.a. protokolliert werden, dass ich hier
>> "vorbei gekommen" bin (das ist erprobt). Aber es passiert nichts. Auch
>> nicht mit onbeforeunload nach [2].
>>
>> Ein anderes Beispiel fand ich bei stackoverflow [3], ich habs etwas
>> abgewandelt, aber das tut auch nichts:
>>
>> <html>
>> <body>
>>       <script>
>>
>>           function goodBye(evt) {
>>               console.log('unload');
>>               return 'good bye';
>>           }
>>
>>           window.onbeforeunload = goodBye;
>> 	
>>       </script>
>> </body>
>> </html>
>>
>> Warum bewirkt das alles nichts?
> 
> 1. <http://glasgoogle.de/> (leider ist unsere FAQ etwas angestaubt)

Leider wusste ich nicht genau, wie ich was fragen und suchen sollte, 
deswegen die unschöne Fragestellung :-).
> 
> 2. Das ist kein gültiges HTML(5): <http://validator.w3.org/>

Weiß ich, taugt aber als Beispiel zum Reden :-).

> 3. Du schreibst auch nicht, mit welchem/-n Umgebungen Du getestet hast.

Nur Firefox, darin soll eine bestimmte Anwendung laufen, ist so vereinbart.

> Vermutlich geht es zumindest teilweise nicht zum Schutz des Benutzers (was
> zeigt die Fehlerkonsole?).  Wäre das nämlich möglich, was Du willst, dann
> könnte jede Website, ohne dass der Benutzer das beeinflussen kann, beim
> Wegnavigieren noch schnell irgendwelche Daten absenden, und der Benutzer
> müsste warten, bis das geschehen wäre (oder definitiv fehlschlüge).

Genau das tut die gefundene Lösung nun. Auszug:

$(document).ready(function () {
    $(window).on('unload', function () {
    $.ajax({
       'url': 'meineaktionen.php',
       'async': false
       // https://stackoverflow.com/a/19274533/9776286
    });
    ...
});

Entscheidend ist das 'async':false, weil eben sonst der Tab/Browser weg 
wäre, bevor die Aktion ausgeführt werden konnte. In meinefunktionen.php 
wird z.B. die laufende Session gekillt, das ist hier wichtig.


> Diese beiden Events (“unload” und “beforeunload”) werden nämlich nicht nur
> gefeuert, wenn das Browserfenster bzw. der Browser-Tab geschlossen wird.

Ja, auch beim Reload, zumindest "beforeunload", das weiß ich.

> Dass in unload- und beforeunload-Listenern nicht alles funktioniert, ist
> bekannt.  Besonders in Firefox sind hier zum Schutz des Benutzers die
> Möglichkeiten für Webentwickler stark eingeschränkt.  Was sicher geht ist
> das Gezeigte: im onbeforeunload-Listener einen String zurückgeben, mit dem
> der Benutzer gefragt werden kann, ob er wirklich wegnavigieren will.
> 
> Beim unload-Event ist es eventuell auch schon zu spät, weil relevante
> Objekte schon nicht mehr verfügbar sind oder währenddessen abgeräumt werden.
>   In jedem Fall ist es eine Race Condition.
> 
> <https://javascript.info/onload-ondomcontentloaded>
> 
> Sessions lässt man am besten bei Logout oder mit Timeout expiren
> (Session-Cookies und Server-Sessions), da man sich nicht darauf verlassen
> kann, dass clientseitiges Scripting verwendet wird.

Gewiss. Hier muss es aber eben auch gehen, wenn das Fenster einfach 
geschlossen wird. Das tut es nun.

> Übrigens ist jQuery hierfür Overkill; daher das einfache Beispiel auf
> Stack Overflow.
Nur funktionieren diese eben nicht, deswegen frage ich ja. Entscheidend 
ist wie gesagt das async, was mit trivialem Javascript nicht als 
Zweizeiler geht. Außerdem habe ich sowieso jQuery, da kann ich es auch 
nutzen.

Ralph

[toc] | [prev] | [next] | [standalone]

#4987

Am 06.12.2018 um 14:24 schrieb Ralph Stahl:

> Thomas 'PointedEars' Lahn schrieb:
>
>> Übrigens ist jQuery hierfür Overkill; daher das einfache Beispiel auf
>> Stack Overflow.
>
> Nur funktionieren diese eben nicht, deswegen frage ich ja. Entscheidend
> ist wie gesagt das async, was mit trivialem Javascript nicht als
> Zweizeiler geht. Außerdem habe ich sowieso jQuery, da kann ich es auch
> nutzen.

Siehe
<https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request>.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#4988

Ralph Stahl wrote:
> Das Problem ist bereits gelöst, 

Nein, Du hast nur ein neues Problem erzeugt.

> siehe unten.

Ja, genau.

> Thomas 'PointedEars' Lahn schrieb:
>> 3. Du schreibst auch nicht, mit welchem/-n Umgebungen Du getestet hast.
> 
> Nur Firefox, darin soll eine bestimmte Anwendung laufen, ist so vereinbart.

Das ist immer noch eine unzureichende Angabe.  Welche Version von Firefox,
welches Betriebssystem?

>> Vermutlich geht es zumindest teilweise nicht zum Schutz des Benutzers (was
>> zeigt die Fehlerkonsole?).  Wäre das nämlich möglich, was Du willst, dann
>> könnte jede Website, ohne dass der Benutzer das beeinflussen kann, beim
>> Wegnavigieren noch schnell irgendwelche Daten absenden, und der Benutzer
>> müsste warten, bis das geschehen wäre (oder definitiv fehlschlüge).
> 
> Genau das tut die gefundene Lösung nun.

Und zusätzlich blockiert sie im Worst Case den Browser komplett, zumindest
aber den entsprechenden Browser-Tab bzw. das -Fenster.

> Auszug:
> 
> $(document).ready(function () {
>     $(window).on('unload', function () {
>     $.ajax({
>        'url': 'meineaktionen.php',
>        'async': false
>        // https://stackoverflow.com/a/19274533/9776286
>     });
>     ...
> });
> 
> Entscheidend ist das 'async':false, weil eben sonst der Tab/Browser weg 
> wäre, bevor die Aktion ausgeführt werden konnte.

Und weil das im Worst Case den Browser komplett blockiert, ist dies
deprecated und demnächst wird die Unterstützung dafür entfernt werden.
So zumindest die Aussage einiger Browserhersteller.

Sieht man deshalb als Warnung in den Chrome Dev Tools (Chromium, Chrome)
in der Script-Console, vermutlich auch in Firefox.

Es ist deshalb zu erwarten, dass das zuerst in onbeforeunload/onunload nicht
mehr funktionieren wird.

> In meinefunktionen.php wird z.B. die laufende Session gekillt, das ist hier wichtig.

Das ist Unsinn, wie bereits erklärt.

>> Diese beiden Events (“unload” und “beforeunload”) werden nämlich nicht nur
>> gefeuert, wenn das Browserfenster bzw. der Browser-Tab geschlossen wird.
> 
> Ja, auch beim Reload, zumindest "beforeunload", das weiß ich.

Du nimmst also in Kauf, dass der Benutzer seinen Browser nicht benutzen
kann, bis sich Dein Server mal bequemt, zu antworten (oder es irgendwann
doch einen Timeout gibt).

>> Sessions lässt man am besten bei Logout oder mit Timeout expiren
>> (Session-Cookies und Server-Sessions), da man sich nicht darauf verlassen
>> kann, dass clientseitiges Scripting verwendet wird.
> 
> Gewiss. Hier muss es aber eben auch gehen, wenn das Fenster einfach 
> geschlossen wird.

Nein, das muss es nicht.  Man setzt einfach ein Session-Cookie, das wird
dann automagisch vom Browser weggeräumt.  Und auf dem Server setzt man das
Session-Expire nicht auf den Sanktnimmerleinstag, sondern z. B. auf 2
Stunden.  Wenn im eingeloggten Zustand eine Aktion stattfindet, macht man
ein Session-Refresh.

>> Übrigens ist jQuery hierfür Overkill; daher das einfache Beispiel auf
>> Stack Overflow.
> Nur funktionieren diese eben nicht,

Doch, das tun sie.  Du hast nur keine Ahnung, was Du tust.


PointedEars (ZCE PHP)
-- 
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4989

Am 06.12.2018 um 14:24 schrieb Ralph Stahl:
> Genau das tut die gefundene Lösung nun. Auszug:
> 
> $(document).ready(function () {
>    $(window).on('unload', function () {
>    $.ajax({
>       'url': 'meineaktionen.php',
>       'async': false
>       // https://stackoverflow.com/a/19274533/9776286
>    });
>    ...
> });
> 
> Entscheidend ist das 'async':false, weil eben sonst der Tab/Browser weg
> wäre, bevor die Aktion ausgeführt werden konnte. In meinefunktionen.php
> wird z.B. die laufende Session gekillt, das ist hier wichtig.

Das verlässt sich drauf, dass der Browser dich im onunload noch Dinge
tun lässt, die Zeit brauchen. Darauf würde ich mich nicht verlassen.

Im Zweifelsfall hat der Nutzer den Browser per Taskmanager beendet (zum
Beispiel, weil er davon genervt war, dass der Browser in einem
synchronen XMLHTTPRequest hing), da wird ein onunload sowieso nicht
ausgeführt.

Besser wäre da eine Lösung, wo der Browser extra eine Socketverbindung
zum Server aufbaut. Wenn das Browserfenster geschlossen wird, egal aus
welchem Grund, wird die Socketverbindung geschlossen; daran kann die
Serverseite erkennen, dass die Session beendet ist. Eine Möglichkeit
wäre ein Websocket. Das braucht serverseitig aber ein wenig mehr als nur
ein paar php-Skripte.

Eine andere Lösung wäre, z.B. alle 10s ein Ping an die Webseite zu
schicken. Empfängt der Server für 30s kein Ping, ist die Session
beendet. Das ist auch mit normalen php-Skripten realisierbar, und ist
speziell im lokalen Netzwerk durchaus vertretbar.


  Stefan

[toc] | [prev] | [next] | [standalone]

#4990

Stefan Reuther wrote:
> Besser wäre da eine Lösung, wo der Browser extra eine Socketverbindung
> zum Server aufbaut. Wenn das Browserfenster geschlossen wird, egal aus
> welchem Grund, wird die Socketverbindung geschlossen; daran kann die
> Serverseite erkennen, dass die Session beendet ist. Eine Möglichkeit
> wäre ein Websocket. Das braucht serverseitig aber ein wenig mehr als nur
> ein paar php-Skripte.

Ich wollte eigentlich schreiben:

Konkret braucht es einen veralteten Browser oder einen sehr versierten
Benutzer, da man sich entschieden hat, WebSocket-Unterstützung aus
Sicherheitsgründen entweder per Default zu deaktivieren oder wieder zu
entfernen.

Jedoch bezieht sich das nur auf eine ältere Version des Protokolls.
Offenbar wird WebSocket (neue Version) inzwischen weithin unterstützt:

<https://caniuse.com/#search=websocket>

(siehe Fussnote 1)

> Eine andere Lösung wäre, z.B. alle 10s ein Ping an die Webseite zu
> schicken. Empfängt der Server für 30s kein Ping, ist die Session
> beendet. Das ist auch mit normalen php-Skripten realisierbar, und ist
> speziell im lokalen Netzwerk durchaus vertretbar.

Aber unnötig, da Session-Cookies automagisch beim Beenden des Browsers
gelöscht werden.  Dann gibt es zwar noch (bis zum Timeout) die
Server-Session, aber keine Möglichkeit mehr, darauf zuzugreifen.  Also alles
im grünen Bereich, oder?

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4991

Am 06.12.2018 um 21:22 schrieb Thomas 'PointedEars' Lahn:
> Stefan Reuther wrote:
>> Besser wäre da eine Lösung, wo der Browser extra eine Socketverbindung
>> zum Server aufbaut. Wenn das Browserfenster geschlossen wird, egal aus
>> welchem Grund, wird die Socketverbindung geschlossen; daran kann die
>> Serverseite erkennen, dass die Session beendet ist. Eine Möglichkeit
>> wäre ein Websocket. Das braucht serverseitig aber ein wenig mehr als nur
>> ein paar php-Skripte.
> 
> Ich wollte eigentlich schreiben:
> 
> Konkret braucht es einen veralteten Browser oder einen sehr versierten
> Benutzer, da man sich entschieden hat, WebSocket-Unterstützung aus
> Sicherheitsgründen entweder per Default zu deaktivieren oder wieder zu
> entfernen.
> 
> Jedoch bezieht sich das nur auf eine ältere Version des Protokolls.
> Offenbar wird WebSocket (neue Version) inzwischen weithin unterstützt:
> 
> <https://caniuse.com/#search=websocket>

Seit 5 Jahren, wenn ich die Werte richtig parse. Kann man also nehmen,
insbesondere, wenn's fürs Intranet ist und man nicht mit Usern aus dem
zentralafrikanischen Busch rechnen muss.

>> Eine andere Lösung wäre, z.B. alle 10s ein Ping an die Webseite zu
>> schicken. Empfängt der Server für 30s kein Ping, ist die Session
>> beendet. Das ist auch mit normalen php-Skripten realisierbar, und ist
>> speziell im lokalen Netzwerk durchaus vertretbar.
> 
> Aber unnötig, da Session-Cookies automagisch beim Beenden des Browsers
> gelöscht werden.  Dann gibt es zwar noch (bis zum Timeout) die
> Server-Session, aber keine Möglichkeit mehr, darauf zuzugreifen.  Also alles
> im grünen Bereich, oder?

Vielleicht möchte der Server die Session dennoch zeitnah loswerden, um
z.B. anderen Nutzern Zugriff zu gewähren. Wordpress und Confluence
machen sowas. Confluence arbeitet offenbar mit 30s-Pings.


  Stefan

[toc] | [prev] | [next] | [standalone]

#4992

Stefan Reuther wrote:
> Am 06.12.2018 um 21:22 schrieb Thomas 'PointedEars' Lahn:
>> Stefan Reuther wrote:
>>> Eine andere Lösung wäre, z.B. alle 10s ein Ping an die Webseite zu
>>> schicken. Empfängt der Server für 30s kein Ping, ist die Session
>>> beendet. Das ist auch mit normalen php-Skripten realisierbar, und ist
>>> speziell im lokalen Netzwerk durchaus vertretbar.
>>
>> Aber unnötig, da Session-Cookies automagisch beim Beenden des Browsers
>> gelöscht werden.  Dann gibt es zwar noch (bis zum Timeout) die
>> Server-Session, aber keine Möglichkeit mehr, darauf zuzugreifen.  Also alles
>> im grünen Bereich, oder?
> 
> Vielleicht möchte der Server die Session dennoch zeitnah loswerden, um
> z.B. anderen Nutzern Zugriff zu gewähren.

Dieses Problem löst man nicht so, sondern mit weiteren User-Accounts.  Dann
ist auch klar, wer der Benutzer ist.

> Wordpress und Confluence machen sowas. Confluence arbeitet offenbar mit 30s-Pings.

Nur weil einige oder sogar viele etwas tun, macht es das noch lange nicht
richtig.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#4995

Thomas 'PointedEars' Lahn:

> Stefan Reuther wrote:
>> Am 06.12.2018 um 21:22 schrieb Thomas 'PointedEars' Lahn:
>>> Stefan Reuther wrote:
>>>> Eine andere Lösung wäre, z.B. alle 10s ein Ping an die Webseite zu
>>>> schicken. Empfängt der Server für 30s kein Ping, ist die Session
>>>> beendet. Das ist auch mit normalen php-Skripten realisierbar, und ist
>>>> speziell im lokalen Netzwerk durchaus vertretbar.
>>>
>>> Aber unnötig, da Session-Cookies automagisch beim Beenden des Browsers
>>> gelöscht werden.  Dann gibt es zwar noch (bis zum Timeout) die
>>> Server-Session, aber keine Möglichkeit mehr, darauf zuzugreifen.  Also alles
>>> im grünen Bereich, oder?
>>
>> Vielleicht möchte der Server die Session dennoch zeitnah loswerden, um
>> z.B. anderen Nutzern Zugriff zu gewähren.
> 
> Dieses Problem löst man nicht so, sondern mit weiteren User-Accounts.  Dann
> ist auch klar, wer der Benutzer ist.

Szenario:

User A öffnet ein Dokument zur Bearbeitung, wofür es exklusiv gesperrt
wird, und der Browser wird beendet, ohne dass die Bearbeitung beendet wurde.

Ohne kurzes Timeout würde diese Sperre u.U. sehr lange bestehen bleiben.
Sessions mit nur für 30 Sekunden Gültigkeit zu haben, will man aber auch
nicht, weil ein Nutzer durchaus mal mehr als 30 Sekunden braucht, um die
Bearbeitung eines Dokuments zu beenden.

>> Wordpress und Confluence machen sowas. Confluence arbeitet offenbar mit 30s-Pings.
> 
> Nur weil einige oder sogar viele etwas tun, macht es das noch lange nicht
> richtig.

Was wäre denn die "richtige" Lösung?


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#4999

On 2018-12-07 20:17, Arno Welzel <usenet@arnowelzel.de> wrote:
> Szenario:
>
> User A öffnet ein Dokument zur Bearbeitung, wofür es exklusiv gesperrt
> wird, und der Browser wird beendet, ohne dass die Bearbeitung beendet
> wurde.
>
> Ohne kurzes Timeout würde diese Sperre u.U. sehr lange bestehen
> bleiben. Sessions mit nur für 30 Sekunden Gültigkeit zu haben, will
> man aber auch nicht, weil ein Nutzer durchaus mal mehr als 30 Sekunden
> braucht, um die Bearbeitung eines Dokuments zu beenden.
>
>>> Wordpress und Confluence machen sowas. Confluence arbeitet offenbar
>>> mit 30s-Pings.
>> 
>> Nur weil einige oder sogar viele etwas tun, macht es das noch lange
>> nicht richtig.
>
> Was wäre denn die "richtige" Lösung?

Im konkreten Fall? 

Auf das exklusive Sperren verzichten und entweder ein Three-Way-Merge
oder eine "Live"-Bearbeitung (a la Etherpad, Google Docs, etc.)
implementieren. Aus Benutzersicht jedenfalls. Aus Entwicklersicht mag
das angesichts dräuender Deadlines anders aussehen.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5000

Peter J. Holzer:

> On 2018-12-07 20:17, Arno Welzel <usenet@arnowelzel.de> 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.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5001

Arno Welzel:

> Peter J. Holzer:
> 
>> On 2018-12-07 20:17, Arno Welzel <usenet@arnowelzel.de> 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

[toc] | [prev] | [next] | [standalone]

#5004

On 2018-12-14 10:34, Arno Welzel <usenet@arnowelzel.de> wrote:
> Arno Welzel:
>> Peter J. Holzer:
>>> On 2018-12-07 20:17, Arno Welzel <usenet@arnowelzel.de> 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.

Kann. Passiert manchmal, aber meiner Erfahrung nach (als jemand, der
seit den 80er-Jahren Versionskontrollsysteme verwendet), recht selten.
Locks hingegen führen meiner Erfahrung nach (als jemand, der seit den
90er-Jahren mit Windows-Applikationen auf SMB-Netzwerkfilesystemen zu
tun hat) mit großer Regelmäßigkeit zu Frustrationen bei den Usern.

(Und ja, ich bin mir bewusst, dass das auch an anderen Faktoren liegt)

>>> 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.

Ich habe nicht behauptet, dass "alle 30 Sekunden Server kontaktieren,
damit die Session nicht ausläuft" falsch ist. Ist habe behauptet, dass
das Sperren eines Dokuments zur Bearbeitung (fast immer) falsch ist.
Und wenn man ein Dokument sperrt, dann ist es ganz sicher falsch, die
Sperre aufzuheben, nur weil man 30 Sekunden kein Lebenszeichen vom
Client bekommen hat. Das kann aus diversen Gründen vorkommen, das wird
vorkommen, und wenn der User dann seine Änderungen verliert, ist er
frustiert. Also muss man diesen Fall behandeln können, und damit ist man
zumindest wieder beim Three-Way-Merge.

Ob "jede Änderung zum Server schicken" die richtige Lösung ist, hängt
von der Art des Dokuments und der Änderungen ab (für Texte ist es
wahrscheinlich gut, für Source-Code eher weniger) und von den sonstigen
Rahmenbedingungen (offline arbeiten? Gemeinsam arbeiten?
Nachvollziehbarkeit?) ab.

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5006

Am 16.12.2018 um 21:22 schrieb Peter J. Holzer:
> On 2018-12-14 10:34, Arno Welzel <usenet@arnowelzel.de> wrote:
>> Arno Welzel:
>>> Peter J. Holzer:
>>>> 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.
> 
> Kann. Passiert manchmal, aber meiner Erfahrung nach (als jemand, der
> seit den 80er-Jahren Versionskontrollsysteme verwendet), recht selten.

Dann hattest du eine behütete Kindheit. Alternativ: ich hab gelegentlich
den Eindruck, dass svn und git vor Situationen kapitulieren, die cvs
noch automatisch gelöst hätte.

In Confluence haben wir zumindest recht häufig Merge-Konflikte gesehen,
bevor auf den Live-Editor umgestellt wurde. In dem sieht man dann den
anderen Nutzer schreiben. Usecases waren halt Dinge wie "User A macht
eine Tabelle, User B+C+D+E fügen jeweils eine Zeile an". Davor
kapituliert der Auto-Merge, weil er nicht weiß, in welcher Reihenfolge
er die neuen Zeilen anfügen soll.

Sowas passiert zwar bei Sourcecode auch, aber doch eher seltener.

> Locks hingegen führen meiner Erfahrung nach (als jemand, der seit den
> 90er-Jahren mit Windows-Applikationen auf SMB-Netzwerkfilesystemen zu
> tun hat) mit großer Regelmäßigkeit zu Frustrationen bei den Usern.

Hier führt das vor allem zu Gelächter in Besprechungen, wenn für einen
Anhang zur Tagesordnung das Popup "Ist noch in Bearbeitung durch X" kommt.

>>>> 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.
> 
> Ich habe nicht behauptet, dass "alle 30 Sekunden Server kontaktieren,
> damit die Session nicht ausläuft" falsch ist.

Indirekt irgendwie schon, aber egal.

> Ist habe behauptet, dass
> das Sperren eines Dokuments zur Bearbeitung (fast immer) falsch ist.
> Und wenn man ein Dokument sperrt, dann ist es ganz sicher falsch, die
> Sperre aufzuheben, nur weil man 30 Sekunden kein Lebenszeichen vom
> Client bekommen hat. Das kann aus diversen Gründen vorkommen, das wird
> vorkommen, und wenn der User dann seine Änderungen verliert, ist er
> frustiert.

Deswegen würde ich in einem Weitverkehrsnetz nicht mit 30s-Timeouts
arbeiten, sondern eher ein paar Minuten.

Im LAN halte ich das für angemessen.


  Stefan

[toc] | [prev] | [next] | [standalone]

#5007

On 2018-12-17 12:25, Stefan Reuther <stefan.news@arcor.de> wrote:
> Am 16.12.2018 um 21:22 schrieb Peter J. Holzer:
>> On 2018-12-14 10:34, Arno Welzel <usenet@arnowelzel.de> wrote:
>>> Arno Welzel:
>>>> Peter J. Holzer:
>>>>> 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.
>> 
>> Kann. Passiert manchmal, aber meiner Erfahrung nach (als jemand, der
>> seit den 80er-Jahren Versionskontrollsysteme verwendet), recht selten.
>
> Dann hattest du eine behütete Kindheit.

So wie ich das geschrieben habe, war es wohl auch nicht richtig.

Ich glaube, man muss drei Arten unterscheiden:

1) Merges, die die Software vollautomatisch durchführen kann (inklusive
Konflikten, die sich automatisch auflösen lassen)

2) Merge-Konflikte, die die Software nicht auflösen kann, die aber für
den Benutzer trivial sind.

3) Merge-Konflikte, die auch für den Benutzer nicht trivial sind.

Die erste Art ist meiner Erfahrung nach mit Abstand die häufigste. Ein
"git merge" läuft in der weit überwiegenden Zahl der Fälle (sicher über
90 %, aber genauer kann ich das nicht sagen) problemlos durch, obwohl
ich ziemlich exzessiv Branches verwende (gestern habe ich z.B. bei einem
Projekt 5 Branches aufgemacht, die ich heute alle wieder in den Master
mergen werde).

Die zweite Art ist viel seltener, kommt auch auch noch recht regelmäßig
vor. Das ist allerdings die Art, die man in einem Web-Interface auch in
einer Weise präsentieren kann, die auch Arnos sprichwörtliche Oma nicht
vor Probleme stellt. 

Die dritte Art, wo man wirklich überlegen und oft noch in anderen Files
oder gar anderen Versionen nachsehen muss, um herauszufinden, wie man
das jetzt am besten bereinigt, ist sehr selten.

> Alternativ: ich hab gelegentlich
> den Eindruck, dass svn und git vor Situationen kapitulieren, die cvs
> noch automatisch gelöst hätte.

Ich mag mich täuschen, aber meiner Erinnerung nach war, CVS nicht
besonders gut darin, Konflikte aufzulösen. Ich sogar mal ein Script
geschrieben, das die oft exzessiv großen Konfliktbereiche minimiert.

Subversion war nur wenig besser. Git ist deutlich besser. Mit git
gehört Branching und Merging für mich zum Arbeitsalltag und auch die
Kollegen nutzen es. Mit Subversion war jeder Merge eine sorgfältig
geplante Aktion und die Kollegen haben das gerne mir überlassen :-/.

>
> In Confluence haben wir zumindest recht häufig Merge-Konflikte gesehen,
> bevor auf den Live-Editor umgestellt wurde. In dem sieht man dann den
> anderen Nutzer schreiben. Usecases waren halt Dinge wie "User A macht
> eine Tabelle, User B+C+D+E fügen jeweils eine Zeile an". Davor
> kapituliert der Auto-Merge, weil er nicht weiß, in welcher Reihenfolge
> er die neuen Zeilen anfügen soll.

Das fällt vermutlich in Kategorie 2 oben. Die Software kann die richtige
Reihenfolge nicht wissen, für den Menschen ist sie meistens trivial. Und
der eigentliche Merge-Vorgang ist dann auch technisch wieder einfach.


> Sowas passiert zwar bei Sourcecode auch, aber doch eher seltener.

Ja, einer der "anderen Faktoren", die ich angespesprochen habe. Bei
manchen Dokumentarten sind überlappende bzw. benachbarte Änderungen
deutlich häufiger als bei anderen. Als Entwickler einer Applikation weiß
man das aber (hoffentlich).


>> Ist habe behauptet, dass das Sperren eines Dokuments zur Bearbeitung
>> (fast immer) falsch ist. Und wenn man ein Dokument sperrt, dann ist
>> es ganz sicher falsch, die Sperre aufzuheben, nur weil man 30
>> Sekunden kein Lebenszeichen vom Client bekommen hat. Das kann aus
>> diversen Gründen vorkommen, das wird vorkommen, und wenn der User
>> dann seine Änderungen verliert, ist er frustiert.
>
> Deswegen würde ich in einem Weitverkehrsnetz nicht mit 30s-Timeouts
> arbeiten, sondern eher ein paar Minuten.
>
> Im LAN halte ich das für angemessen.

Es gibt auch Gründe, die wenig mit der Netzwerkverbindung zu tun haben.
Von durch eine andere Webapplikation lahmgelegten Browsern bis zu
Leuten, die ihr Notebook zuklappen, um ins Besprechungszimmer zu gehen. 

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5008

Am 20.12.2018 um 13:32 schrieb Peter J. Holzer:
[Lock vs. Merge]
> 1) Merges, die die Software vollautomatisch durchführen kann (inklusive
> Konflikten, die sich automatisch auflösen lassen)
> 
> 2) Merge-Konflikte, die die Software nicht auflösen kann, die aber für
> den Benutzer trivial sind.
> 
> 3) Merge-Konflikte, die auch für den Benutzer nicht trivial sind.
> 
> Die erste Art ist meiner Erfahrung nach mit Abstand die häufigste. Ein
> "git merge" läuft in der weit überwiegenden Zahl der Fälle (sicher über
> 90 %, aber genauer kann ich das nicht sagen) problemlos durch, obwohl
> ich ziemlich exzessiv Branches verwende (gestern habe ich z.B. bei einem
> Projekt 5 Branches aufgemacht, die ich heute alle wieder in den Master
> mergen werde).
> 
> Die zweite Art ist viel seltener, kommt auch auch noch recht regelmäßig
> vor. Das ist allerdings die Art, die man in einem Web-Interface auch in
> einer Weise präsentieren kann, die auch Arnos sprichwörtliche Oma nicht
> vor Probleme stellt. 

Selbst, wenn man sich auf die ersten zwei Fälle beschränkt: das erhöht
die Komplexität der Software *und der Nutzerführung* um Größenordnungen.

Für 1) muss ich überhaupt erstmal einen Merge-Algorithmus haben - und
sei es, dass ich meine Daten in eine Form bringe, dass ein
Standard-Merge-Tool damit umgehen kann. Wenn das, was ich da editiere,
kein reiner Text ist, ist das schon mal nicht trivial.

Für 2) muss ich eine Benutzerführung bauen, die dem Nutzer verständlich
anzeigt, was er da tun muss (wie stelle ich dar, dass der konkurrierende
Bearbeiter das Wort fett gemacht hat, welches ich unterstreichen
wollte?). Ich muss damit umgehen können, dass während der
Konfliktauflösung ein weiterer Bearbeiter den Text editiert.

Damit hast du aus dem "Nutzer müssen in der Lage sein, Artikeldetails
über die Webschnittstelle bearbeiten zu können" aus dem Dreitages- ein
Dreimonatsprojekt gemacht.

Mit Locking: ganz normales Editierfeld. 'setInterval(function(){ new
XmlHttpRequest(...).send() }, 30000)' (oder gar ganz ohne Javascript,
<iframe> mit Refresh-Intervall). 'if (time() < $db->{time} - 100)'. Fertig.

>> Alternativ: ich hab gelegentlich
>> den Eindruck, dass svn und git vor Situationen kapitulieren, die cvs
>> noch automatisch gelöst hätte.
> 
> Ich mag mich täuschen, aber meiner Erinnerung nach war, CVS nicht
> besonders gut darin, Konflikte aufzulösen. Ich sogar mal ein Script
> geschrieben, das die oft exzessiv großen Konfliktbereiche minimiert.
> 
> Subversion war nur wenig besser. Git ist deutlich besser. Mit git
> gehört Branching und Merging für mich zum Arbeitsalltag und auch die
> Kollegen nutzen es. Mit Subversion war jeder Merge eine sorgfältig
> geplante Aktion und die Kollegen haben das gerne mir überlassen :-/.

git hat vor allem rebase, mit dem man den Merge-Aufwand schön in kleine
Stücke schneiden kann...

>> Deswegen würde ich in einem Weitverkehrsnetz nicht mit 30s-Timeouts
>> arbeiten, sondern eher ein paar Minuten.
>>
>> Im LAN halte ich das für angemessen.
> 
> Es gibt auch Gründe, die wenig mit der Netzwerkverbindung zu tun haben.
> Von durch eine andere Webapplikation lahmgelegten Browsern bis zu
> Leuten, die ihr Notebook zuklappen, um ins Besprechungszimmer zu gehen. 

Das wäre dann die philosophische Frage, ob man in diesem Usecase das
Lock aufrechterhalten will, oder ob man den Nutzer einfach aus der
Editorsitzung rauswirft (Status vielleicht als noch nicht
veröffentlichten Entwurf speichern und dem nächsten Bearbeiter
präsentieren) und ihn sich nach Wiederankunft in der Zivilisation eine
neue machen lässt.


  Stefan

[toc] | [prev] | [next] | [standalone]

#5009

On 2018-12-22 10:56, Stefan Reuther <stefan.news@arcor.de> wrote:
> Selbst, wenn man sich auf die ersten zwei Fälle beschränkt: das erhöht
> die Komplexität der Software *und der Nutzerführung* um Größenordnungen.

Ja, gute User-Interfaces sind aufwändig. Schlechte User-Interfaces kann
man meistens schnell hinprogrammieren.

(Auf den Zeit-Aspekt habe ich aber bereits in meinem ersten Posting in
diesem Thread hingewiesen, du erzählst mir da also nichts neues).

        hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel

[toc] | [prev] | [next] | [standalone]

#5010

Peter J. Holzer:

> On 2018-12-22 10:56, Stefan Reuther <stefan.news@arcor.de> wrote:
>> Selbst, wenn man sich auf die ersten zwei Fälle beschränkt: das erhöht
>> die Komplexität der Software *und der Nutzerführung* um Größenordnungen.
> 
> Ja, gute User-Interfaces sind aufwändig. Schlechte User-Interfaces kann
> man meistens schnell hinprogrammieren.

Die Software wird auch dann aufwendiger, wenn das User-Interface
weitgehend gleich bleibt.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#5002

Am 14.12.2018 um 00:03 schrieb Peter J. Holzer:
> On 2018-12-07 20:17, Arno Welzel <usenet@arnowelzel.de> wrote:
>>>> Wordpress und Confluence machen sowas. Confluence arbeitet offenbar
>>>> mit 30s-Pings.
>>>
>>> Nur weil einige oder sogar viele etwas tun, macht es das noch lange
>>> nicht richtig.
>>
>> Was wäre denn die "richtige" Lösung?
> 
> Im konkreten Fall? 
> 
> Auf das exklusive Sperren verzichten und entweder ein Three-Way-Merge

Das macht die Aufgabe gleich um Größenordnungen komplizierter. Und zwar
nicht nur in der Programmierung, sondern auch in der Benutzung. "Das
Dokument ist gerade in Bearbeitung bei <Nutzer>" versteht Oma Brömmel,
das kennt sie von Excel. Eine Merge-GUI nicht.

> oder eine "Live"-Bearbeitung (a la Etherpad, Google Docs, etc.)
> implementieren.

Wenn man sich für Live-Bearbeitung entscheidet (auch das ist in allen
Metriken um Größenordnungen komplizierter), ist die Signalisierung des
geschlossenen Browserfensters aka "Nutzer hat die Editor-Sitzung
abgebrochen" ein zu lösendes Teilproblem.


  Stefan

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.lang.javascript

csiph-web