On Aug 3, 2010, at 2:43 AM, David Chisnall wrote: > 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. > That sounds really promising. :-)
> 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. Yes, we'll want this. The general case is compressing a sequence of operations to get another sequence which does the same thing, with fewer operations (removing redundant ops.) I achieve the same thing in ObjectMerging in a lazy way; I just load the start and end states and do an object graph diff, so any sentences that were typed and then deleted won't show up in the diff output. There may be some clever ways to do it without reconstructing the states and doing a diff. I remember reading that Mercurial had some clever algorithm for removing redundancy from deltas, I'll have to check out what they were doing. --Eric _______________________________________________ Etoile-dev mailing list Etoile-dev@gna.org https://mail.gna.org/listinfo/etoile-dev
