Zielsetzungen:

• => Für einen Editor kann die exklusive Bearbeitungsberechtigung (= Reservierung) für Eigenschaften von openWIM-Objekten ("Obj") angefordert und eingetragen werden.
  
• => Mit Beenden des Editierens wird die exklusive Bearbeitungsberechtigung wieder gelöscht.
• => Die Editier-Blockade von Objekten soll möglichst gut - aber auch benutzerfreundlich - verhindert werden.
  • => Bei "verlassenen" Editoren wird nach einer Warnung und Wartezeit die Reservierung entzogen, falls andere Reservierungswünsche vorliegen.

Typische Verläufe beim Editieren:

• Mit Starten des Editors wird für die zu bearbeitenden Eigenschaften eines Objektes (ggf. alle) eine exklusive Änderungsberechtigung ("Reservierung") angefordert ('setWriteLock').
• Beim Server wird geprüft, ob der (zuvor eingeloggte) Autor die zum Editieren angemeldeten Daten überhaupt ändern darf.
• Ggf. wird die Reservierung verweigert ('lackOfAuthorization')
• Dann wird überprüft, ob alle angeforderten Daten nicht bereits von jemand anderem zum Ändern reserviert wurden.
• Ggf. wird die Reservierung verweigert ('alreadyLocked')
• Ansonsten wird die Reservierung bestätigt und bei der initialen Reservierung eine frisch generierte Zufallszahl als Reservierungscode übergeben ('writeLocked').
  Der Reservierungscode wird benötigt, wenn Änderungsaktionen an den reservierten Daten durchgeführt werden sollen - also beim Speichern der bearbeiteten Daten.
• Vom Editor ist anzugeben, für welchen Zeitraum die Reservierung gelten soll. Dieser Zeitraum wird ggf. auf einen minimalen bzw. maximalen Wert eingegrenzt.
• Mit etwas Reserve zum Ablauf des Reservierungszeitraums wird vom Service eine Nachricht zum bevorstehenden Ablauf des Reservierungszeitraums an den Client geschickt
• Wenn der Editiervorgang beim Client als aktiv erscheint (Mausbewegungen etc. in den vergangenen 10(?) Minuten) wird postwendend eine erneute Reservierung, die die vorangegangene Reservierung ablöst, unter Angabe des bisherigen Reservierungscodes gesendet.
• Wird vom Client keine fristgerechte Reservierungsanforderung geschickt, wird die Reservierung vom Service beendet und alle Reservierungsdaten dazu werden gelöscht. Dem Client wird davon informiert ('writeLockClosed'). Andere Clients können dann die zuvor reservierten Daten für sich reservieren.
  (tbd: Hier gäbe es die Möglichkeit, zuvor abgewiesene Reservierungen nun nachträglich zu bestätigen. Zumindest aber eine Nachricht über eine nunmehr mögliche Reservierung zu schicken.)
• Vom Service kann bei einem Reservierungskonflikt vom Client eine explizite Reservierungsbestätigung angefordert werden:
• Wird der Editor noch aktiv genutzt (Mausbewegungen etc. in den vergangenen 5(?) Minuten), wird die Reservierungsanforderung postwendend automatisch wiederholt. 
• Falls noch keine Warnung (mit Countdown-Zähler?) zum Abbruch der Reservierung dargestellt ist, wird dieses jetzt veranlasst.
• Ansonsten wird bei abgelaufenem Countdown KEINE Verlängerung der Reservierung angefordert.
• (tbd: Falls beim Editor eine automatische Speicherung eingestellt ist, wird eine Speicherung der geänderten Daten [und dann eine Beendigung der Reservierung?] veranlasst.)
   
• Wird die Bearbeitung von Obj-Daten beendet, wird vom Editor eine Reservierung mit dem zugeteilten Reservierungscode aber einer "leeren" Angabe ( [] )für die zu reservierenden Daten an den Service gesendet.
• Vom Service wird eine Bestätigung zur Beendigung der Reservierung gesendet (writeLockClosed)
   
• Bei der Bearbeitung eines Objektes können auch Änderungen an Daten verknüpfter Objekte notwendig werden. Soll beispielsweise eine neue Themenverknüpfung hinzugefügt werden, müssen vor der Änderung der Daten zur Verknüpfung eine Reservierung für das verknüpfte Obj durchgeführt werden. Das bedeutet, dass im Editor neben der Bearbeitungs-Reservierung der eigenen Daten auch noch eine oder mehrere Reservierungen für weitere Obj-Daten erfolgen muss /müssen.
   

ppp