Etherpad-lite: Verlangsamen Sie mit vielen verschiedenen Beiträgen (~ @ 700 Zeilen)

Ich sehe dies nicht in Firefox Nightly 23.0a1 (2013-04-27) oder 19.0.2, aber in Google Chrome Version 26.0.1410.65 mit http://etherpad-lite.paas.allizom.org/p/kqOi9HF97Z (der sich gerade im Entwicklungszweig c8e2278afcb4f75d52af6e55ebe1e979461c63fc befindet) auf Mac OS X 10.7.5 (2.53 GHz Intel Core i5). Ich kann Firefox nicht über 50% CPU bringen, aber ich kann den Google Chrome Renderer-Prozess leicht dazu bringen, 100% zu erreichen (nur zufälliges Scrollen und Tippen in beiden Fällen).

Es scheint in Firefox auf diesem Computer verwendbar zu sein, aber ich würde zustimmen, dass es in Chrome zu langsam ist, um verwendet werden zu können.

Ich habe mir den Chrome Profiler kurz angesehen (habe gerade keine Zeit, mich weiter damit zu befassen) und die lange Stange scheint in einer minimierten Quelle zu sein, ich denke, es ist eine Abfrage - sie verbringt die meiste Zeit in t.event.dispatch -> am Griff

Gibt es eine schnelle Möglichkeit, etherpad-lite lokal gegen unminified jquery auszuführen, damit ich den echten Stack sehen kann (nicht sicher, was ich tun muss, damit die Quellkarten jetzt dafür funktionieren, werde das auch untersuchen)?

Ach egal, ich sehe es in settings.json, wird es lokal mit deaktivierter Verkleinerung starten und sehen, ob etwas Nützlicheres auftaucht.

Los geht's, elemData.handle (unten) beansprucht 32,83% der CPU-Zeit auf meinem Laptop:

setSelection
  updateBrowserSelectionFromRep
    inCallStack
      inCallStackIfNecessary
        handleKeyEvent
          jQuery.event.dispatch
            elemData.handle

Als nächstes folgt scrollNodeVerticallyIntoView mit 18,38 %, dann addRange mit 6,58%. Alles darunter ist vernachlässigbar (unter 2%)

Bestätigt auch langsam auf http://beta.etherpad.org/p/cA9CbQlmTY

Das Problem besteht in 1.2.0 aus meinen Tests, daher wird eine Halbierung wahrscheinlich nicht helfen;

Für diesen Fehler existiert jetzt eine Testspezifikation. https://github.com/ether/etherpad-lite/pull/1764

Dieser Fehler bestand in der ursprünglichen Version von Etherpad

Das Auskommentieren von https://github.com/ether/etherpad-lite/blob/develop/src/static/js/ace2_inner.js#L4501 scheint die Leistung bis zu dem Punkt zu verbessern, an dem der Test in Chrome erfolgreich ist und nicht scheint anfangs auffällige negative Nebenwirkungen haben, aber ich kann nicht anders, als zu denken, dass mit diesem Fix etwas nicht stimmt, bin mir nur nicht sicher, warum wir zuerst AllRanges entfernen.

Dokumente für removeAllRanges... https://developer.mozilla.org/en-US/docs/DOM/Selection/removeAllRanges

FF scheint im Umgang mit großen Pads gut zu sein, Chrome und IE tun sich schwer. Der IE hat für den Test keinen Speicher mehr und ist auf einem großen Pad fast unbrauchbar.

Ich denke, das wird eine ernsthafte Untersuchung erfordern, um zu sehen, ob wir das, was blockiert, umgehen können. Ich bin ziemlich erschöpft mit meiner Zeit/Ressourcen, um das jetzt zu werfen.

Also habe ich in Google Docs nach einem Lösungsvorschlag gesucht und es stellte sich heraus, dass die Fähigkeit von Google Docs, lange Dokumente in einer kollaborativen Umgebung zu verarbeiten, noch schlimmer ist. Ich werde versuchen, einen stabileren Test zu schreiben, aber ich würde vorschlagen, dies tatsächlich zu lösen, könnte etwas sexy Magie erfordern.

Dies kann sehr wohl das Problem sein, das ich bei mehr als 25.000 Bearbeitungen gesehen habe, da dies größtenteils lange Dateien sind. In allen Fällen waren diese Pads ebenfalls 700 - 1000 Zeilen lang.

Also ich würde das - https://github.com/ether/etherpad-lite/issues/1380 einen Dupe-Bug nennen

Ich habe kleinere Pads gesehen, die die Trennung eines einzelnen Clients erzwingen, wenn versucht wird, die Autorship-Farben im gesamten Dokument zu löschen. Wäre dies verwandt oder wäre dies ein anderes Problem?

@iuriguilherme wahrscheinlich völlig unabhängig

Dieser Fehler könnte zusammenhängen mit: https://bugs.webkit.org/show_bug.cgi?id=92594

Dieser Fehler lässt es so klingen, als würde die derzeitige Implementierung des Editors zu einem Seitenlayout für jeden Tastendruck in Webkit-Browsern führen.

Hilft der Pull Request #1833 bei diesem Problem?

@dirkcuys , es hilft, aber löst dieses Problem nicht. Es verringert die Geschwindigkeit, mit der schnelle aufeinander folgende Tastenanschläge die Reaktionsfähigkeit verringern. Dies erhöht die Reaktionsfähigkeit im allgemeinen Fall um eine Größenordnung. Es gibt mehr Anmerkungen in der PR.

@dlongley danke. Ich habe versucht, die Änderungen in der Pull-Anfrage auf einem Server unter http://pad.p2pu.org/ anzuwenden, aber ich erhalte mit Chromium 28.0.1500.71 auf Ubuntu 12.04 immer noch eine fast unbrauchbare Leistung.

Irgendwelche Vorschläge? Ich erwäge ein Downgrade auf Version 1.1.5? Ist das ratsam/möglich?

afaik besteht das Problem in Etherpad seit Tag 0.

@dirkcuys , ein Downgrade wird wahrscheinlich nicht helfen. Wenn Sie genug Inhalt in Ihren Blöcken haben, wird es langsam, Punkt. Der PR hilft, das Problem ein wenig zu mildern (die Geschwindigkeit der Leistungsverschlechterung ist langsamer), aber es ist nicht die eigentliche Lösung. Das Problem kann nur auf zwei Arten gelöst werden: ein Fix für das Webkit, damit die Seite nicht so oft gestaltet wird oder eine Änderung des Designs von Etherpad, damit nicht für jedes Zeichen in . ein separates DOM-Element verwendet wird das Pad. Wirklich, beide Fixes sollten irgendwann passieren. Die Kombination, das Seitenlayout für jeden Tastendruck neu zu erstellen und eine _Tonne_ von Elementen, die angeordnet werden müssen, ist der Killer.

Beim Webkit wurde ein Fehler gemeldet, um sein Verhalten zu ändern, damit es mehr träge / konsolidierte Updates durchführt. Es ist nur unklar, ob jemand bald daran arbeiten wird. Hier könnten wir mit etherpad lite einen ähnlichen faulen Ansatz verfolgen, indem wir den Inhalt nur in separate DOM-Elemente aufteilen, wenn mehrere Personen denselben Bereich eines Pads bearbeiten. In diesem Fall können wir für die meisten großen Pads einige echte Leistungssteigerungen sehen, aber es ist ein komplizierteres Design, um es richtig zu machen.

Gibt es für jedes Zeichen ein separates DOM-Element? Wenn man sich ein Pad in den Chrome-Entwicklertools ansieht, sieht es so aus, als gäbe es nur ein div für jede Zeile und dann einen Span für den Beitrag jedes Autors in jeder Zeile. Der einzige Weg, den ich sehen könnte, um DOM-Elemente zu reduzieren, wäre, Zeilen mit demselben Autor (oder Zeilen ohne Autor) in demselben Div zu kombinieren. Das Problem würde bei stark kollaborativen Dokumenten weiterhin bestehen bleiben, bis die Autorenfarben gelöscht wurden.

Das kann der Grund sein, warum ich das Problem nicht einfach alleine reproduzieren kann. Ich verwende Ubuntu und Chromium Version 28.0.1500.71 Ubuntu 13.04 (28.0.1500.71-0ubuntu1.13.04.1) und habe den gesamten Text von Hamlet (insgesamt 4741 Zeilen) in ein Pad mit dem PR eingefügt und während die Verzögerung war nach dieser Paste bemerkbar, war es immer noch sehr brauchbar.

Natürlich war ich der einzige im Block und der gesamte eingefügte Text stammte von mir, daher macht es Sinn, dass die Leistung bei großen Dokumenten mit einer großen Anzahl von Autoren pro Zeile viel schlechter wäre (Da gäbe es viel mehr Autorenfarbe Spannen im DOM). Könnte eine schnellere Lösung darin bestehen, die Anzahl der verschiedenen Autorenfarbspannen in einem Block weich zu begrenzen? Es könnte eine periodische Hintergrundaufgabe geben, die die ältesten Farbspannen des Autors entfernen könnte, bis das Limit unterschritten ist.

Gibt es für jedes Zeichen ein separates DOM-Element? Wenn man sich ein Pad in den Chrome-Entwicklertools ansieht, sieht es so aus, als gäbe es nur ein div für jede Zeile und dann einen Span für den Beitrag jedes Autors in jeder Zeile.

Ja, tut mir leid, es ist pro Zeile. Um einen Überblick über mein Verständnis der Vorgänge zu geben (in Webkit-Browsern):

1. Der Benutzer drückt während der Eingabe eine Taste.
2. Etherpad-lite (ace) fügt dem vorhandenen Span einen Buchstaben hinzu.
3. Etherpad-lite aktualisiert die Fensterauswahl, die Webkit veranlasst, die Seite zu gestalten.
4. Etherpad-lite berechnet Änderungen.
5. Etherpad-lite generiert und fügt eine neue DOM-Zeile (div+span+etherpad-lite-spezifisches Attributmaterial) ein, die den gerade eingegebenen Buchstaben enthält und dann den alten entfernt (wodurch mehr Layouts ausgelöst werden).

Wenn Sie Tausende von Zeilen auf der Seite haben, dann passiert jedes Mal, wenn Sie beim Tippen eine Taste drücken, das Obige _sehr langsam_. Das Zurückstellen von Seitenlayouts im Webkit oder das Ausführen einer DOM-Kombination oder ein langsameres Aktualisieren auf der Etherpad-Lite-Seite sollte dieses Problem beheben.

Der einzige Weg, den ich sehen könnte, um DOM-Elemente zu reduzieren, wäre, Zeilen mit demselben Autor (oder Zeilen ohne Autor) in demselben Div zu kombinieren. Das Problem würde bei stark kollaborativen Dokumenten weiterhin bestehen bleiben, bis die Autorenfarben gelöscht wurden.

Das Kombinieren von DOM-Elementen würde helfen, ebenso wie das Verzögern von Aktualisierungen und das Umgestalten, wie die Aktualisierungen erfolgen, zB: unnötige Einfügungen/Löschungen zu reduzieren.

Das kann der Grund sein, warum ich das Problem nicht einfach alleine reproduzieren kann. Ich verwende Ubuntu und Chromium Version 28.0.1500.71 Ubuntu 13.04 (28.0.1500.71-0ubuntu1.13.04.1) und habe den gesamten Text von Hamlet (insgesamt 4741 Zeilen) in ein Pad mit dem PR eingefügt und während die Verzögerung war nach dieser Paste bemerkbar, war es immer noch sehr brauchbar.

Die PR hat vielleicht auch ein bisschen geholfen. Aber ja, ein Pad, das nur von einer einzigen Person bearbeitet wurde, führt nicht so schnell zu einer Verlangsamung wie eines mit vielen Änderungen durch verschiedene Personen. Die Verlangsamung nimmt mit der Anzahl der DOM-Elemente zu, die ausgelegt werden müssen.

Könnte eine schnellere Lösung darin bestehen, die Anzahl der verschiedenen Autorenfarbspannen in einem Block weich zu begrenzen? Es könnte eine periodische Hintergrundaufgabe geben, die die ältesten Farbspannen des Autors entfernen könnte, bis das Limit unterschritten ist.

Ja, das würde das Problem etwas mildern. Ich bin mir jedoch nicht sicher, ob dies eine Lösung ist, die Leute mit diesem Problem möchten. Trotzdem verlangsamt ein einzelner Editor, wenn das Pad groß genug ist, die Dinge mehr als eigentlich akzeptabel (oder als "gute Leistung") angesehen werden sollte.

Es ist ein paar Monate her seit dem (sehr geschätzten) Debugging-Sprint oben: Wenn ich das richtig verstehe, wurde das Problem analysiert und identifiziert, oder?
Welche Art von Hilfe wird benötigt, um diesen Schritt zu machen? Jetzt, da 1.3 veröffentlicht und Korruptionsprobleme hoffentlich gelöst wurden, ist dies (wieder) der Hauptblocker für die breite Verwendung von Etherpad lite bei Wikimedia.

Das Problem scheint zu sein, dass der Browser viel zu tun hat. Wir könnten wahrscheinlich hier und da ein paar Teile optimieren, aber wenn wir keinen völlig anderen Editor-Prozessablauf finden, ist das Problem immer noch, dass es viel zu tun gibt.

Was tun Sie, wenn Sie viele Aufgaben schnell ausführen möchten? Sie führen sie parallel. Eine Option wäre also, einige dieser Aufgaben in Webworker zu übertragen.

Welche Aufgaben könnten einem Webworker übertragen werden? Nichts DOM-bezogenes.

Welche Aufgaben könnten einem Webworker übertragen werden? Nichts DOM-bezogenes.

@marcelklehr , ich glaube nicht, dass

So können wir beispielsweise vermeiden, bei jedem Tastendruck eine komplette DOM-Zeile zu entfernen und eine neue einzufügen ( siehe Punkt 5 ). Der Code sollte intelligent genug sein, um zu wissen, wann Sie in einen Bereich tippen, den Sie bereits "besitzen", damit er keine zusätzliche Arbeit leisten muss. Ich gehe davon aus, dass der aktuelle Code so geschrieben wurde, wie er war, weil er einfach und konsistent war; es wurde einfach nicht optimiert. Es kann jedoch sein, dass einige andere Redesign-Arbeiten dazu beitragen könnten, diese Art von speziellen Optimierungen ganz zu vermeiden. Es wäre hilfreich, wenn der ursprüngliche Autor dieses Codes einen Kommentar abgeben könnte, er/sie jedoch möglicherweise nicht verfügbar ist.

Es gibt nicht viel, was wir tun können (ohne den Webkit-Code zu bearbeiten), um den Layout-Code selbst zu verbessern (beachten Sie, dass Firefox dieses Problem nicht hat), aber die Häufigkeit der Layouts könnte reduziert werden.

Welche Art von Hilfe wird benötigt, um diesen Schritt zu machen?

@nemobis , es muss ein Vorschlag vorgelegt werden, der einen Teil des Kern-Editor-Designs ändern würde, um zusätzliche Layouts zu vermeiden und die Anzahl der verwendeten DOM-Elemente auf etwas skalierbareres zu reduzieren. Um das Problem richtig zu lösen, muss wahrscheinlich noch einiges an Arbeit geleistet werden, um die Funktionsweise des Haupteditors zu überarbeiten und die Urheberschaft im DOM zu erhalten. Der Code selbst ist schwer nachzuvollziehen und muss neu organisiert und besser kommentiert werden, damit die Designentscheidungen (und die daraus resultierenden Einschränkungen) gut verstanden werden.

okay. Macht Sinn.

@dlongley wer sind die ursprünglichen Autoren? Können sie zu diesem Ticket hinzugefügt werden?

Ein großer Teil dieses Codes wird vom ursprünglichen Etherpad-Stack geerbt , also würde ich wahrscheinlich nicht

@nemobis , was @JohnMcLear gesagt hat ... das habe ich mir gedacht. Es ist "Legacy" -Code, mit dem meiner Meinung nach niemand, der an etherpad-lite arbeitet, allzu vertraut ist (zumindest hat er kein Eigentum daran). Vielleicht bedarf es allein aus diesem Grund etwas Aufmerksamkeit und Umgestaltung (und Kommentaren), damit eine Situation wie diese nicht wieder auftritt, in der es für niemanden schwierig ist, sie ohne großen Aufwand zu übernehmen. Ich würde sagen, das ist das größte Hindernis, um eine Lösung zu finden. Ich würde gerne reingehen und es reparieren und ein paar Redesign-Arbeiten machen, aber ich habe im Moment einfach keine Zeit.

@dlongley Ist dies etwas, das Sie bald überprüfen könnten?

@JohnMcLear , ich denke, es gibt einige Bereiche, in denen die Situation verbessert werden kann (wie in https://github.com/ether/etherpad-lite/issues/1763#issuecomment-27576051 angegeben), leider ist es unwahrscheinlich, dass ich ' Ich werde bis frühestens nächstes Jahr viel Zeit haben, sie persönlich anzusprechen. Ich habe in diesem Jahr eine Reihe von Fristen für andere Projekte zu erledigen.

Etwas anderes, was die Community hier tun könnte, ist hart Lobbyarbeit, um diese Fehler zu beheben:

https://code.google.com/p/chromium/issues/detail?id=423170
https://code.google.com/p/chromium/issues/detail?id=138439
https://bugs.webkit.org/show_bug.cgi?id=92594

Wenn Sie diese beheben, kann die Leistung in Chrome mit Firefox vergleichbar sein. Letztendlich wäre es am besten, die oben genannten Designprobleme zu beheben, aber die Behebung dieser Blink-/Webkit-Fehler könnte einen großen Beitrag zur Verbesserung der Leistung leisten.

Von diesem ersten Chromfehler - siehe diese Geige: http://jsfiddle.net/eJeQC/

Ich bin mir ziemlich sicher, dass das das gleiche Problem (mit der gleichen Ursache) ist, das wir hier mit Etherpad sehen. Beachten Sie, dass es in Firefox schnell ist (Warnungen mit ~0 ms, wenn Sie in den Ergebnisbereich klicken) und in Chrome sehr langsam (~100 ms+, je nach Hardware).

@dlongley Um ehrlich zu sein, nächstes Jahr wäre in Ordnung, wir fühlen uns damit wohl, dass sich die Dinge langsam bewegen, da es sich lohnt, die richtige Lösung zu finden.

@dlongley Hey Mann, du hattest, das genauer zu untersuchen ? :)

Ich bin im Moment noch zeitlich festgeschnallt. Ich denke jedoch, der richtige Ansatz zur Lösung dieses Problems, wahrscheinlich einer Reihe anderer Fehler und der Verbesserung der Wartung, wäre:

1. Schreiben Sie den Core-Editor mit einer neuen Version von Ace neu . Ich denke, etherpad-lite sollte eine eher abhängigkeitsbasierte Beziehung zu Ace haben (Installation über das Modul im Vergleich zu stark modifizierten Check-ins einer sehr alten Version (2009)). Dies würde es uns ermöglichen, Fixes von Ace unabhängig von etherpad-lite einzuholen und eine Menge wartungsbedingter Fehler zu entlasten, die Codebasisgröße von etherpad-lite zu reduzieren, Bedenken auf den Mehrwert von etherpad-lite zu beschränken und die Dinge daher einfacher zu halten Entwickler usw.
2. Das Kerndesign von Etherpad-lite sollte darauf ausgerichtet sein, Änderungen an einem Ace-Dokument (von mehreren Benutzern) zu verfolgen, zu speichern und zu übertragen, mehr nicht. Oben auf dem Kern sollte die gleiche Art von Feature-Set sein, die es jetzt gibt (grundlegende UI-Sachen, Farben auswählen, Verlauf anzeigen usw.; hoffentlich müssten wir beim Ändern des Kerns nicht zu viele Änderungen an anderer Stelle vornehmen). Kurz gesagt, nach einer Neufassung von Core sollten wir immer noch alle Funktionen und ein ähnliches Gefühl haben wie zuvor, aber der Umfang von Core wäre angemessen begrenzt, der Code wäre leichter zu verstehen und wir könnten uns auf etherpad-lite konzentrieren Funktionen, anstatt sich um den zugrunde liegenden Editor selbst zu kümmern.
3. Da ich immer wenig Zeit habe, habe ich mir nur kurz die APIs von Ace angesehen, aber es scheint, als würde der erste Schnitt bei einem Redesign das Schreiben einer EditSession beinhalten , die Änderungen verfolgt, sie an den Server übermittelt und Änderungen von anderen Benutzern applyDeltas auf das freigegebene Dokument angewendet werden. Ich habe nicht alles untersucht, was in ein Ace-Änderungsobjekt einfließt oder was etherpad-lite derzeit für Änderungen serialisiert; Wir müssen möglicherweise das Format aktualisieren oder etwas schreiben, um ältere Pads zu konvertieren. Wir bräuchten immer noch eine Möglichkeit, Meta-Tags auf Elementen zu belassen, die beim Anwenden jedes Deltas geändert wurden (um für verschiedene Benutzer einzufärben) -- aber vielleicht kann auch hier etwas Einfaches / Cleveres getan werden. Ich habe es nicht untersucht; vielleicht gibt es sogar eine Möglichkeit, einen benutzerdefinierten Syntax-Highlighter zu missbrauchen, um dies zu erreichen.

Es gibt noch mehr Details zu durcharbeiten, aber dies ist nur ein Ausgangspunkt, um über ein Redesign nachzudenken, das etherpad-lite von seiner alten und scheinbar nicht wartbaren Kerncodebasis befreien würde. Hoffentlich kann der neue Kern auf einer viel höheren Abstraktionsebene entwickelt werden, wie oben vorgeschlagen, wobei die gesamte Verarbeitung von Eingabeereignissen, das Rendern, das Herumspielen mit Bereichen usw. an Ace delegiert wird. Ich denke, diese Art der Neufassung des Kerns ist wahrscheinlich der beste Ansatz für die langfristige Gesundheit von etherpad-lite. Und es kann sich herausstellen, dass es tatsächlich der einfachste Weg ist, dieses "Schwarze Loch"-Problem zu lösen.

Ich würde das gerne irgendwann selbst machen, aber wenn jemand da draußen ist, der es vor mir schaffen kann, bitte tun Sie dies auf jeden Fall. Ich werde auch auf Kommentare antworten und Design-Feedback/Hilfe geben, wenn ich kann, falls jemand anderes Lust hat, daran zu arbeiten.

Ich habe @nightwing für 1

@dlongley RE 1 siehe http://etherpad.googlecode.com/hg/trunk/infrastructure/ace/README - die beiden haben nichts miteinander zu tun . ACE- und Ajax-Editor.

@JohnMcLear , ah, das sehe ich jetzt (siehe auch: https://groups.google.com/forum/#!topic/etherpad-lite-dev/0uU_LXp_iPg). Es schien, als würden wir vielleicht nur eine sehr veraltete Version verwenden. Vielleicht sollten wir in Erwägung ziehen, zum ACE-Editor von c9 zu wechseln. Ich muss die Unterschiede noch genauer untersuchen; Letztendlich bestand das Endziel darin, die gesamte Bearbeitung, die Behandlung von Ereignissen auf niedriger Ebene usw. in ein anderes Paket zu übertragen und etherpad-lite sich auf die Echtzeitverfolgung und Synchronisierung von Änderungen mehrerer Benutzer im selben Dokument zu konzentrieren. Im Moment erfordert etherpad-lite, dass wir uns mit dem Low-Level-Editor-Engineering befassen, und es wäre eine große Verbesserung, wenn dies vollständig vermieden werden könnte.

Obwohl ich die Unterschiede zwischen dem ACE-Editor von c9 und (ACE - A ppJet C ode E ditor) nicht überprüft habe, weiß ich jedoch, dass der ACE von c9 ziemlich modern ist, aktiv gewartet wird und anscheinend eine API hat, die wir nutzen können die Funktionen von etherpad-lite auf einer höheren Abstraktionsebene zu implementieren.

c9 ACE verwendet keine editierbaren Inhalte, die mobile Unterstützung funktioniert auch nicht. :(

Trotz des unglaublichen Interesses an diesem Thema scheint es immer noch an mobilem Support zu mangeln: https://github.com/ajaxorg/ace/issues/37

Unabhängig davon denke ich, dass etherpad-lite nur dann gewartet werden kann, wenn wir alle grundlegenden Bearbeitungssachen auf niedriger Ebene entfernen und uns dafür auf ein anderes beliebtes Projekt/Modul verlassen. Wenn der mobile Support ein Deal Breaker ist, sollten wir entweder sehen, ob wir helfen können, ihn zu ACE hinzuzufügen, oder einen anderen Editor als Abhängigkeit auswählen.

ACE hat eine großartige Leistung, ist beliebt (== gute Wartung) und hat eine gute API. Wir können überprüfen, wie andere Editoren zusammenpassen, aber wir müssen Projekte vermeiden, die keine starken Gemeinschaften um sich herum haben oder die erheblichen benutzerdefinierten Low-Level-Bearbeitungscode erfordern, um die Kernfunktionen von etherpad-lite zu implementieren. Grundlegende Bearbeitungsfehler, wie insbesondere dieser, sollten nicht in die Domäne von etherpad-lite fallen.

Wenn etherpad-lite dies noch nicht tut, sollte es auch einen klaren Bruch zwischen dem Speichern/Serialisieren von Änderungen an Dokumenten und dem verwendeten Editor haben. IOW sollte es eine einfache Übersetzungsschicht geben, die serialisierte Änderungen in den/von dem Editor umwandelt, den wir letztendlich verwenden. Wir sollten in der Lage sein, Redakteure bei Bedarf mit so wenig Änderungen wie möglich auszutauschen. Dies ist nur ein Ideal; es ist vielleicht nicht so einfach zu erreichen.

Im Moment habe ich noch begrenzte Zeit. Ich überlege jedoch, wie dieses Problem richtig gelöst werden kann, vielleicht einige andere Fehler, und die Wartung in einem besseren Zustand zu halten, wird sein:

1. Schreiben Sie den Core-Editor mit der neuen Version von Ace neu . Ich denke, etherpad-lite sollte eine eher abhängigkeitsbasierte Beziehung zu Ace haben (Installation über Module, anstatt ein stark modifiziertes Einchecken für eine sehr alte Version (2009)).Auf diese Weise können wir unabhängig von Acepad-lite Fixes von Ace beziehen, eine Vielzahl von wartungsbedingten Fehlern deinstallieren, die Codebasis von Etherpad-lite verkleinern und den Fokus auf den Mehrwertumfang von Etherpad beschränken. lite Um Entwicklern die Arbeit zu erleichtern usw.
2. Das Kerndesign von Etherpad-lite sollte sich um das Verfolgen, Speichern und Übertragen von Änderungen an Ace-Dokumenten (von mehreren Benutzern) drehen, mehr nicht. Oberhalb des Kerns sollten sich die gleichen Funktionen befinden, die jetzt vorhanden sind (grundlegender UI-Inhalt, Farben auswählen, Verlauf anzeigen usw.; hoffe, dass wir beim Ändern des Kerns nicht zu viele Änderungen an anderer Stelle vornehmen müssen). Kurz gesagt, nach dem Neuschreiben des Kernels sollten wir immer noch alle Funktionen haben und sich ähnlich anfühlen wie zuvor, aber der Umfang des Kernels wird entsprechend eingeschränkt, der Code wird leichter zu verstehen sein und wir können uns auf etherpad-lite-Funktionen konzentrieren. Ohne sich um den grundlegenden Editor selbst zu kümmern.
3. Da ich immer beschäftigt bin, habe ich Aces API nur kurz vorgestellt, aber es scheint, dass der erste Schritt beim Redesign darin besteht, eine EditSession zu schreiben, um Änderungen zu verfolgen, Änderungen an den Server zu kommunizieren und Änderungen von anderen Benutzern vom Server zu empfangen. Jeder Benutzer muss nur seine eigene EditSession für das Dokument erhalten. Die Änderungen werden in oder aus JSON serialisiert, zumindest scheint es, dass es mit einem einfachen Aufruf des freigegebenen Dokuments über applyDeltas als Änderungssatz verwendet werden kann . Wir können (oder müssen nicht) das Format aktualisieren oder etwas schreiben, um die alte Tastatur zu konvertieren. Ich habe es nicht studiert; vielleicht gibt es sogar eine Möglichkeit, einen benutzerdefinierten Grammatik-Highlighter zu missbrauchen, um dies zu erreichen.

Es gibt noch mehr Details zu klären, aber dies ist nur der Ausgangspunkt, um über ein Redesign nachzudenken, das etherpad-lite von seiner alten, scheinbar nicht wartbaren Kerncodebasis befreien kann. Es ist zu hoffen, dass der neue Kernel als eine höhere Abstraktionsebene wie oben beschrieben entworfen werden kann und die gesamte Verarbeitung von Eingabeereignissen, Rendering, Bereichsverwirrung usw. an Ace delegiert werden kann. Ich denke, diese Neufassung des Kernels ist möglicherweise der beste Weg, damit etherpad-lite langfristig gesund bleibt. Darüber hinaus stellt sich heraus, dass dies tatsächlich der einfachste Weg ist, dieses "Schwarze Loch"-Problem zu lösen.

Ich möchte das irgendwann selbst machen, aber wenn das vor mir jemand kann, bitte. Wenn jemand möchte, werde ich auch auf Kommentare antworten und Design-Feedback/Hilfe geben.