Derby 0.5.0 überarbeitet mangelhafte Racer-Engine
Kommentare

Asynchrone Zusammenarbeit in Web-Anwendungen erfordert einiges an Backend-Logik. So muss die Engine stets wissen, wie sie mit Konflikten umgehen soll. Ständig kommt es zu widersprüchlichen Änderungen,

Asynchrone Zusammenarbeit in Web-Anwendungen erfordert einiges an Backend-Logik. So muss die Engine stets wissen, wie sie mit Konflikten umgehen soll. Ständig kommt es zu widersprüchlichen Änderungen, die aber den User nicht bei der Arbeit behindern sollen. Selbst beim Online-Office-Klon(-Versuch) Google Docs hat es einige Zeit gedauert, und auch das Derby-ähnliche Wave-Framework (Derzeit im Apache-Inkubator) unterliegt ständiger Optimierung.

Das Zauberwort hinter der simultanen Datenmanipulation ist „Operational Transformation„; ein Verfahren, das das Hinzufügen, Löschen, und das Editieren konfliktfrei abwickelt. Auf Hacker News erklärt Derby-Entwickler Nate Smith dazu:

OT is done at the document level. Documents are JSON objects of arbitrary complexity. Any mutation of the JSON object can be composed against any other mutation of the JSON object.

Firepad doesn’t actually do OT of JSON. In Firepad, a string OT algorithm is used to merge text edits, and the metadata describing rich text is separately managed as span objects, which get modified in accordance with text changes.

Firebase provides conflict resolution of JSON structures using their Transaction primitive, which allows them to create a Software Transactional Memory used to update the journal that powers the text OT in Firepad. ShareJS inside of Derby uses a similar approach to allow multiple servers to access the journal, but it is done in Redis with Lua scripting.

Dies zu implementieren, dauerte jedoch vor Derby noch Monate. Jetzt gibt es Beispiele, wie das eines zweiköpfigen Entwicklerteams, das an einem Nachmittag ein kollaboratives Kreatives-Schreiben-Spiel realisiert, wie das Video zeigt:

Mit Derby 0.5.0 wurden erhebliche Schwierigkeiten mit dem Backend Racer.js beseitigt, indem man es auf ShareJS-Basis neu geschrieben hat. Memory Leaks und generelle Stabilitätsprobleme sollen damit stark reduziert worden sein. Bis zur Version 1.0 stehe den Entwicklern und Testern dennoch viel „Bug Hunting“ bevor.

Falls Ihr bereits Derby verwendet und auf die stabilere Version upgraden wollt, solltet Ihr einen Blick auf den Migration Guide werfen. Der Code an sich liegt auf GitHub unter MIT-Lizenz zum Forken bereit.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -