nicht angemeldet
Unterschiedliche Zeitabläufe
Rolf BHallo,
es gibt folgende Situation.
Es gibt eine Liste von Menschen, die unterschiedlich lang und unabhängig voneinander an einem Text auf einer Webseite arbeiten dürfen. Einer z.B. 30min, andere 45min usw. Nun soll nach dem Ablauf von 30min der erste nicht mehr an dem Text arbeiten dürfen, der andere darf aber noch weitermachen. Der Admin soll auch in der Lage sein, alle Zeitabläufe in einer Liste sehen und kontrollieren können.
Wie kann man dies am besten realisieren? Threads? Oder gibst einen anderen, einfacheren Weg?
Gruß
-
„unterschiedlich lang und unabhängig voneinander an einem Text auf einer Webseite arbeiten dürfen“
... ist viel zu ungenau. Hier Fragen, die mir auf der Stelle einfallen:
- Soll es feste Zeiten geben, wer wann darf?
- Sollen ein Texte auch gleichzeitig von mehreren Personen bearbeitet werden dürfen?(¹)
- Wie willst Du Konflikte vermeiden?
- Was soll dann bei Bearbeitungs-Konflikten passieren?
- Sollen diese Bearbeiter die Resultate der anderen Bearbeitungen „live“(²) sehen? Wenn ja: Wie soll mit der Zeitverzögerung umgegangen werden
- Was für eine Art „Text“ ist das? JSON, XML, YAML, Flüche, Gedichte, Romane, Drehbücher - das alles ist „Text“. Ja; Diese Frage ist wegen des weiteren Vorgehens relevant.
- Soll das Resultat der Bearbeitung ggf. vor einer Speicherung oder des Weitersendens an die anderen Teilnehmer formal und/oder inhaltlich geprüft werden?
- Wo und wie soll das Resultat der Bearbeitung gespeichert werden?
¹) Klingt nach einer guten Idee ... daran haben sich auch schon viele daran versucht. Die Ergebnisse haben es stark nötig, stark beschönigend beworben zu werden. Womöglich weil die Idee eines solchen „Webeditors für eine gemeinsame Bearbeitung“ nur gut klingt.
²) Das ist schon nicht wirklich live - allenfalls „zeitnah“ (ca. 1 Sekunde Verzögerung wird es wohl geben) - möglich. Mit allen daraus resultierenden Problemen (→ Konfliktlösung)
-
Hallo,
danke für deine Antwort.
Um auf deine Fragen einzugehen: Nein, das soll nicht so aufwendig werden. Also kein gleichzeitiges Bearbeiten und somit keine Konflikte.
Man muss es am Besten als eine Art Formular vorstellen, die eine Gruppe zu Gesicht bekommt. Jeder hat, abhängig vom Alter, der Erfahrung usw. mehr oder weniger Zeit, die Fragen zu beantworten. Am Ende werden die Ergebnisse separat auf dem Server abgespeichert.
Die Anfangsliste mit den Zeiten sind in einer DB abgelegt. Ich habe gedacht, ich starte mehrere Threads. Ich weiß aber nicht, wie diese sich verhalten. Zu wenig Erfahrung in dem Bereich.
Gruß
-
Ich habe gedacht, ich starte mehrere Threads.
Darum musst Du Dich nicht kümmern.
Willi und Lisa haben einen Benutzernamen und ein Passwort.
Beim Anmelden wird auf dem Server nachgeschaut, ob die schon (und noch) dürfen. Die TN bekommen eine Session-ID, den Text und den Zeitpunkt des Ablaufs - oder die Fehlermeldung. Beim Speichern wird auf dem Server geprüft, ob die noch dürfen, ggf. rechtzeitig per JS ein Speichern beim Fristablauf erzwungen. Kommen die Daten auf dem Server an, wird die Berechtigung nochmals geprüft. Alle relevanten Handlungen der TN werden auf dem Server gespeichert („geloggt“), für den Admin aufbereitet und zum Abruf feilgeboten (oder in ein Terminal geschrieben).
Du hast also einerseits den Server und die Browser (ggf. das Terminal) und das sind nicht nur „Threads“ sondern sogar Prozesse - (außer in speziellen Fällen) auf völlig verschiedenen Maschinen.
-
-
Hallo Lowterm,
Threads?
Da wir hier von einer Weblösung reden, gibt es keine Maschine, auf der diese Threads laufen könnten.
Webseiten arbeiten auf Request-Response Basis. Der Browser schicht eine Anfrage, der Server verarbeitet sie möglichst schnell, und schickt eine Antwort. Diese stellt der Browser dar.
Was bedeutet "am Text arbeiten" bzw. "nicht mehr arbeiten dürfen"? Wenn ich in meinem Browser irgendwas bearbeite, passiert das nur im Browser. Um die Änderungen zum Server zu bringen, gibt es zwei Möglichkeiten:
- Der Anwender drückt einen Speichern-Button
- Ein JavaScript-Programm macht alle paar Sekunden einen Snapshot des aktuellen Bearbeitungsstandes und schickt ihn per HTTP Request (siehe fetch-API) zum Server.
Ein "nicht mehr arbeiten dürfen" kann am Server so dargestellt werden, dass er nach Ablauf der Bearbeitungszeit keine Änderungen von diesem Anwender mehr annimmt. Dafür muss er registrieren, wann der Anwender mit der Bearbeitung begonnen hat. Dafür verwendet man eine Steuertabelle, in der alle Anwender vermerkt sind, möglicherweise ein Zeitfenster, wann sie arbeiten dürfen und der Beginnzeitpunkt der Bearbeitung. Vielleicht auch noch ein Zeitpunkt, wann sie zuletzt etwas gespeichert haben.
Mit dieser Tabelle, die beispielsweise in einer SQL DB gespeichert sein kann, kannst Du alles erschlagen.
Die übrigen Themen, die Raketenwilli nannte, sind auch interessant, aber nicht direkt im Kontext deiner Frage.
Rolf
--
sumpsi - posui - obstruxi-
Hallo Rolf,
danke. Dass das über JavaScript/ajax oder ähnlichen Mechanismus laufen muss, ist mir bekannt. Man kann sich z.B. die "Worker" zunutze machen. Kann man eigentlich einen Thread zur Laufzeit manipulieren bzw. die Zeit, wann er endet, beeinflussen?
Gruß
-
Kann man eigentlich einen Thread zur Laufzeit manipulieren bzw. die Zeit, wann er endet, beeinflussen?
Wem „gehört“ der Browser? Alles, was relevant ist, muss außerhalb des Machtbereichs der Benutzer - also auf dem Server - geprüft werden. Sonst nehm ich Curl statt eines Browsers - und Du wirst das nicht merken.
Rezept: Weniger Buzzwörter („Worker“, „Thread“) gebrauchen, einfacher denken, einfache Grundregeln einfach beachten.
-
Hallo Lowterm,
Worker - meinst Du das Webworker-API im Browser? - sind dann sinnvoll, wenn Du eine echte Parallelität der Verarbeitung haben willst. Für eine Zeitüberwachung sind sie ungeeignet. Du kannst im Worker auch nichts anderes tun als im Haupt-Thread: Einen Timer setzen und nach Ablauf signalisieren, dass die Zeit rum ist. Der Worker macht Dir die zusätzliche Arbeit, das Signal zunächst an den Haupt-Thread des Browsers zu schicken.
Beeinflussen kannst Du mit Hilfe der Entwicklerwerkzeuge des Browsers sehr viel. Deswegen ist auf NICHTS, was im Browser passiert, irgendein Verlass.
Wenn Du dem Anwender signalisieren willst, dass die Bearbeitungszeit abgelaufen ist, liefere die verbleibende Zeit mit, wenn Du die Seite an den Browser schickst und lasse per JavaScript einen Intervalltimer laufen, der zum Beispiel im Sekundentakt die Restzeit anzeigt. Das mit der verbleibenden Zeit ist wichtig, weil der Anwender ja z.B. die Seite refreshen kann (was blöd wäre weil dann die Eingaben weg sind) und die Restzeit dann immer noch stimmen muss.
Den Verlust der Eingabedaten kannst Du verhindern, indem das JavaScript im Hintergrund die Daten in kurzen Abständen aus dem Formular liest und entweder am Server oder im LocalStorage zwischenspeichert. Vor allem für Grobmotoriker wie mich, die täglich einmal Strg+W statt Shift+W drücken, wäre das ein Geschenk des Himmels.
Kurz vor Ende der Zeit kann das Script warnen und bei Ablauf das Formular sperren. Mit Hilfe eines Ajax-Requests im Hintergrund kann das Script - zum Beispiel 5 Sekunden vor Schluss - die Eingaben sichern und nochmal die Restzeit abholen, um sicher zu sein, dass nicht zu früh gesperrt wird. Wenn es wirklich wichtig ist, die Eingabe sekundengenau zu beenden und den aller-allerletzten Stand bei Fristablauf auf dem Server zu haben, kann der Server etwas Kulanz walten lassen und Uploads noch wenige Sekunden nach Fristablauf zulassen. Wenn viele Leute mit dem System arbeiten und alle gleichzeitig fertig werden, musst Du aber sehr vorsichtig sein und ggf. Gnade walten lassen. Je nach Leistungsfähigkeit des Servers kann es dann sein, dass die Verarbeitung der Einsendungen sich staut. Eventuell musst Du die Einsendungen dann erstmal nur 1:1 auf dem Server speichern, in der Datenbank die Einsendung vermerken und die Daten im Hintergrund weiterverarbeiten, wo es die Benutzer nicht blockieren kann. Echtzeitprogrammierung für viele Anwender ist definitiv kein Spaß, und ein solches System muss sehr gut auf sein Lastverhalten getestet werden.
Der Teil im Browser ist aber nicht ausreichend. Der Browser steht unter Kontrolle des Anwenders und ist jeglicher Manipulation ausgesetzt. Schlimmer noch, wie Raketenwilli sagte, es muss gar kein Browser sein; es kann auch ein anderes Tool sein, das die HTTP Requests absetzt. Jede fachlich oder sicherheitstechnisch relevante Überprüfung muss vom Server durchgeführt werden.
Threads helfen Dir hier generell nicht weiter. Die Browser/Webserver Welt ist etwas ganz anderes als ein Desktop-Programm. Auf dem Desktop hast Du einen einzigen User, und du kannst in einem Programm einen Hintergrund-Thread laufen lassen, der eine Zeit abmisst und nach Ablauf signalisiert, dass das Formular zu sperren ist.
Wenn ein Webserver sowas täte, würde er sehr schnell an seine Leistungsgrenzen kommen. Ein Webserver beschäftigt sich im Normalfall nur dann mit einem seiner Clients, wenn der einen Request schickt. Darauf gibt's eine Antwort, und der Client ist wieder vergessen. Alles, was zwischen der Response und dem nächsten Request erinnert werden muss, wird vom Serverprogramm in der Session oder in einer Datenbank gespeichert. Nur so ist es möglich, mit einem einzigen Server sehr viele Anwender zu bedienen. Würde der Webserver pro aktivem Nutzer einen Thread erzeugen und aktiv laufen lassen, wäre er viel schneller am Anschlag.
Es gibt Ausnahmen. Mit Server-sent Events oder Websockets gibt es Protokolle, bei denen der Server aktiv etwas an den Client schicken kann. Die sind aber in klassischen Webservern nicht vorhanden, die benötigen spezielle Applicationserver, mit denen sich sowas machen lässt.
Wie schon beschrieben ist das für Dich nicht nötig. Deine Zeitüberwachung kannst Du mit einfachen Timestamps in einer Datenbank realisieren. Für den Anwender reicht die informative Anzeige per JavaScript im Browser
Rolf
--
sumpsi - posui - obstruxi-
Hallo,
danke euch beiden. Jetzt habe ich besseres Verständnis dafür, was vor mir steht.
LG
-
-