展望Meteor創建一個協作文檔編輯應用程序，因爲默認情況下Meteor在多個客戶端之間同步數據是非常棒的。Meteor的Etherpad風格同步？
但薩米爾Kalburgi的例子使用文本區域時，如
http://www.skalb.com/2012/04/16/creating-a-document-sharing-site-with-meteor-js/
http://docshare-tutorial.meteor.com/
經驗是次優的。
我試着在同一時間與一位同事打字，而當她打字時我的更改將被覆蓋，反之亦然。所以在衝突解決方案中，我認爲還沒有合併算法呢？
這是計劃用於該功能嗎？目前有什麼方法可以實現？ Etherpad似乎很好地處理了這個問題。在Meteor中擁有這一點可以使創建協作文檔編輯應用程序變得更容易。
你所描述的似乎是出於Meteors範圍之外。它不是建立協作可能性的工具！
它提供的是一種透明地處理服務器數據庫子集的方法。但是用例特定的合併功能的實現是應用程序的工作，而不是框架。
所以我看着它更多一些，在EtherPad的使用的算法被稱爲操作轉換：
的解決方案是操作轉換（OT）。如果您還沒有聽說過，OT是一類可以執行多站點實時併發的算法。 OT就像實時混帳。它適用於任何數量的延遲（從零到延長的假期）。它可讓用戶以低帶寬進行實時併發編輯。 OT爲您提供多個用戶之間的最終一致性，無需重試，沒有錯誤，也沒有任何數據被覆蓋。
不幸的是，實施OT很糟糕。有一百多種算法有不同的折衷，大多數都被困在學術論文中。這些算法非常耗時且難以正確實施。我們需要一些好的庫，所以任何項目如果需要的話都可以插入OT。
這是來自sharejs的網站。基於node.js的服務器客戶端，您可以掛接到您的現有客戶端。
OT也在Node.js的Racer模型同步引擎中實現，它構成了Derby的基礎。目前，derby.js沒有透明地提供過，但他們計劃過，從Derby docs：
目前，賽車默認爲順序應用所有交易獲得的，即最後寫入者勝。 （...）Racer [另外]支持通過軟件事務存儲器（STM），操作轉換（OT）和Diff-match-patch技術的組合來解決衝突問題。
這些功能尚未完全實現，但Racer演示顯示STM和OT的初步示例。
巧合的是，sharejs和derbyjs團隊都有一個前谷歌搖擺不定的人。流星在他們的核心團隊中擁有一個以前的etherpad/Google Waver。由於EtherPad的是我想象流星一定會想在某個時候支持以及OT最著名的實現方式之一...
我創建了一個流星智能封裝，集成了ShareJS：
它現在是相當初步的，但你可以將其導入到你的應用程序，在textarea小號下降，它「只是工程」。請嘗試，並且通過引入請求:)這裏
退房演示提交了一些新的特點：
演示鏈接已死亡。 – qznc 2016-07-16 17:55:46
恕我直言，這些類型的應用程序的整點不只是客戶端透明地與服務器同步，但通過這種方式，所有連接的用戶都可以相互同步。如果這不是爲了合作的可能性，我不知道是什麼！ – 2012-08-14 19:31:02
而且由於衝突解決方案是建立在Meteor之中的，所以問它是否可以更復雜一點似乎並不是一個奇怪的問題。但是，當然，如果你知道一個好方法，我可以自己調整衝突解決機制，我想知道。 – 2012-08-14 19:34:25
好的，我的措辭可能有點偏離。我的意思是，流星當然支持協作場景，但並沒有明確地面向它。所以你不得不期待一些粗糙的邊緣。你的意思是「內置衝突解決方案」？在文檔中我可以找到的所有方面都是在衝突情況下，第一個客戶端訂閱總是獲勝。 – 2012-08-15 17:52:56