On 2 Aug 2010, at 23:56, Eric Wasylishen wrote: >>> So for typing a document, doing a commit after every key press would >>> probably be excessive, but after 5 words or something (IMHO the >>> undo/redo granularity you get in OS X when typing is just right.) >> >> I don't know. CO consumes disk space very quickly in my tests, so recording >> every key press sounds like a bad idea. A compression scheme could solve the >> problem or not. >> If the recording granularity is bigger, we should still try to lose no key >> press :-) > > Good point - ideally you won't lose even one key press.
I did some tests ages ago with a version of Typewriter.app modified to use its NSTextStorage via EtoileSerialise (back before it grew a z in its name). It used about 4% of my CPU without and 6% with, while typing as fast as I could (this was back on my 1.2GHz Celeron M). The tar.bz2 of the resulting changes was about as big as the generated text file - it compressed very well because it was basically the same few messages being sent each time, with just a one or two character difference. It would be nice, particularly for sharing, if changes that cancelled each other out could be omitted. For example, if I type a sentence, then delete it, these changes should not be recorded for sharing (but probably should for my local copy, unless I explicitly delete them). OpenOffice.org's (incredibly slow and buggy) change tracking does this, which is about the only nice thing about it. This would require some knowledge of exactly what the messages meant, but maybe not much. As long as CO knew what part of the document each message modified, it could see if one overwrites another. For a text document, this would be a range with replace or renumber operations. With an image it would just be a set of points. David -- Send from my Jacquard Loom _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
