When working with very large documents, would it basically overwhelm the connection and ground to a halt or successfully manage using diffs?
When working with very large documents, would it basically overwhelm the connection and ground
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When working with very large documents, would it basically overwhelm the connection and ground to a halt or successfully manage using diffs?
In short: diff
Each time someone hits a key in an etherpad document, all connected participants get a short message (some 100 byte + some kilobyte or so of HTTP headers and stuff)
Bandwidth will not be the first bottleneck, so don’t worry about saturating (“filling up”) your bandwidth with an etherpad lite server. The underlying framework (node.js) on its own perhaps could (static files etc), but the etherpad lite code surely will be limited by CPU speed and possibly disk space. (The classical ehterpad can generate GB of disk log files per day and I don’t know if “lite” is defaulting to more limited logging, but you can of course change that or simply delete old log files)
I’ve poked around the old/original etherpad and etherpad lite uses the same methods for handling text documents. No document is stored “in full” but always as a set of changes. The changes are run “play back” to recreate the document. To avoid playing back thousands of tiny changes, there are aggregate changes stored in the database (so you playback changes in log10 time scale).