文檔共享/聊天應用的安全方法？

Question

我的一位朋友和我一直在使用谷歌文檔一段時間，但似乎是在不支持她的瀏覽器了，所以作爲一個有趣的項目，我想我會嘗試模仿自己的功能。

到目前爲止，我已經建立了一個工作傳真在笨（PHP）的作品在我的機器上本地的罰款;然而，我試圖弄清楚這是否是最有效的方法/最安全的釋放其他人。 （請記住，這並不意味着是一個公共服務;只是供大多2人，也許3-4最多）

應用程序的每個頁面都有一個聊天室，爲無論視圖目前的文件是;這些都是獨立刷新。聊天室基本上從每次用戶提交消息時更新的.txt文件中提取;聊天會通過每秒兩次的JQuery AJAX調用進行返回。 （到目前爲止，我並不打算在用戶離開聊天時進行註釋，但我認爲這需要單獨進行投票。）

文檔視圖也通過AJAX更新，但調用控制器函數以ping一個記錄MySQL數據庫;此調用每秒發生一次，以及用戶更新文檔時。

顯然，這將必須在託管計劃，可以從規則的Javascript適應通信呼叫，但放在一邊，這是解決這個問題一種可接受的方式？它會對客戶端（或服務器端）造成過度的壓力嗎？有沒有更好的辦法？我非常自學成才，儘管我能夠做出一些有效的工作，但我很樂意確認我沒有采取錯誤的做法。

謝謝！希望這個問題是有道理的;很高興在必要時進行闡述。

Answer 1

我認爲投票會導致結垢問題，儘管這可能不是這樣的小環境的問題。我不是這方面的專家，但我懷疑如果可能的話，你想要使用的模型是在你的服務器上留下一個打開的套接字，這樣事件（即其他人的編輯，甚至只是信號刷新來自數據庫的內容）可以從服務器推送，而不需要輪詢。有一種叫做Comet的技術。當然，你需要爲BOTH構建支持，以防萬一像強制代理或限制性防火牆阻礙了開放套接字的發展，並且你需要恢復輪詢。

在服務器端，優化優化優化。如果您正在輪詢，請確保您測試的是最後一次更新的時間戳，這些更新保存在數據中的單獨，較小且正確索引的表中。

對於聊天，爲什麼不利用現有的一些工具，在那裏？有優秀的IRC客戶，如IRIS。使用IRC服務器也可能爲多個用戶協調他們的行爲提供更好的方式。例如，可能有一個以文件標識符命名的通道，該通道由JS處理程序加入，該處理程序通知其他人的光標位置，待處理的編輯（以及由此產生的需要從數據庫刷新文檔）等。我並不建議這是最好的方式，但這至少是一個有趣的想法。

我很樂意看到你拿出代碼！可用的多用戶Google文檔克隆將非常受歡迎。