You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
"Modale Operationen" sind Operationen, die (aus Nutzersicht) durch einen Zeitraum und nicht einen Zeitpunkt definiert sind, z.B. Feature umbenennen oder Beschreibung ändern. Das aktuelle Konzept betrachtet bei solchen Operationen nur den "Submit"-Zeitpunkt, was unintuitiv ist und nicht alle Konflikte abdeckt.
Idee für modale Operationen:
Bei Beginn (Umbenennungs-Fenster wird geöffnet) stoppe Empfang von Nachrichten (cache in ingoingQueue).
Bei Ende (Abbruch oder Bestätigung) fahre damit fort (arbeite zunächst ingoingQueue ab).
Zwei Konsequenzen:
Im Hintergrund passiert nichts mehr, wir bekommen nichts von anderen Aktionen mit. Kann man positiv oder negativ sehen.
Garbage Collection wird unmöglich, sobald irgendjemand einen modalen Vorgang abwickelt. Das ist sehr blöd. Einfache "Lösung": Darauf hoffen, dass modale Vorgänge kurz sind (sind sie in der Regel, z.B. umbenennen). Softes Kriterium einführen: Falls der modale Vorgang ungewöhnlich lange (> 1min oder so) dauert, weise den Nutzer darauf hin: "Bitte schließe den Vorgang bald ab, da..." (technischer Grund: GC funktioniert sonst nicht) "...sonst mit hoher Wahrscheinlichkeit ein Konflikt auftritt." Ist keine wirklich elegante Lösung, würde aber klappen.
Modale Operationen sind wichtig und müssen irgendwie gehandlet werden. Insb. nehmen Teilnehmer schnell Konflikte wahr (Bsp. Umbenennung, einer klickt früher auf "Rename", der andere wird beim Umbenennen unterbrochen), die das System so im Moment (zeitpunktbasiert) nicht erkennt. Deshalb ist diese Variante (ingoingQueue oben) vmtl. dem aktuellen Verhalten vorzuziehen.
Note to myself: Descriptions sind blöd. Die sind potenziell lang und die modalen Operationen dann auch (zeitlich). Insb. können (im Moment) nie zwei Leute an einer Description arbeiten, ohne einen Konflikt zu verursachen. Da will man also entweder OT oder was Vergleichbares drüberlegen (schwierig?) oder Descriptions komplett aus dem System entfernen. Das Problem ist in diesem Fall aber weniger der Umgang mit modalen Operationen, sondern dass Descriptions ein großer Blob sind und das auf jeden Fall zu Problemen führt. Evtl. Descriptions komplett extern editieren (anderer Server nötigenfalls) und dann das Endergebnis regelmäßig im Hauptserver sichern, dabei komplett den Kernel und MOVIC umgehen (gar keine Set-Description Operation). Schlimmstenfalls einfach Etherpad in einem iframe ;)
The text was updated successfully, but these errors were encountered:
"Modale Operationen" sind Operationen, die (aus Nutzersicht) durch einen Zeitraum und nicht einen Zeitpunkt definiert sind, z.B. Feature umbenennen oder Beschreibung ändern. Das aktuelle Konzept betrachtet bei solchen Operationen nur den "Submit"-Zeitpunkt, was unintuitiv ist und nicht alle Konflikte abdeckt.
Idee für modale Operationen:
Bei Beginn (Umbenennungs-Fenster wird geöffnet) stoppe Empfang von Nachrichten (cache in ingoingQueue).
Bei Ende (Abbruch oder Bestätigung) fahre damit fort (arbeite zunächst ingoingQueue ab).
Zwei Konsequenzen:
Modale Operationen sind wichtig und müssen irgendwie gehandlet werden. Insb. nehmen Teilnehmer schnell Konflikte wahr (Bsp. Umbenennung, einer klickt früher auf "Rename", der andere wird beim Umbenennen unterbrochen), die das System so im Moment (zeitpunktbasiert) nicht erkennt. Deshalb ist diese Variante (ingoingQueue oben) vmtl. dem aktuellen Verhalten vorzuziehen.
Note to myself: Descriptions sind blöd. Die sind potenziell lang und die modalen Operationen dann auch (zeitlich). Insb. können (im Moment) nie zwei Leute an einer Description arbeiten, ohne einen Konflikt zu verursachen. Da will man also entweder OT oder was Vergleichbares drüberlegen (schwierig?) oder Descriptions komplett aus dem System entfernen. Das Problem ist in diesem Fall aber weniger der Umgang mit modalen Operationen, sondern dass Descriptions ein großer Blob sind und das auf jeden Fall zu Problemen führt. Evtl. Descriptions komplett extern editieren (anderer Server nötigenfalls) und dann das Endergebnis regelmäßig im Hauptserver sichern, dabei komplett den Kernel und MOVIC umgehen (gar keine Set-Description Operation). Schlimmstenfalls einfach Etherpad in einem iframe ;)
The text was updated successfully, but these errors were encountered: