Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modale Operationen #38

Open
ekuiter opened this issue Jun 11, 2019 · 1 comment
Open

Modale Operationen #38

ekuiter opened this issue Jun 11, 2019 · 1 comment

Comments

@ekuiter
Copy link
Owner

ekuiter commented Jun 11, 2019

"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 ;)

@ekuiter
Copy link
Owner Author

ekuiter commented Jun 11, 2019

see #34 for the last paragraph

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant