Hacker News Reader

Comment by chj | Hacker News Reader

The op missing is string diff. If a very long string value has changed, no matter how little the change is, you'll have to include the entire string in the patch.

View on HN

If you have strings that long, maybe it would be wise to break it up semantically into some collection of resources (paragraphs, lines, etc.). It could be reassembled as needed for display but then stored and updated as its semantic parts.

Taken to an extreme (and isn't that what programming is all about), that could end up using a lot more memory and overhead, storing an array of many short strings, instead of storing one big flat string. And it would also require more work and pointless code complexity to deal with many short strings.

As opposed to the pointless complexity that comes from implementing support for string diffs?

Having implemented a json differ (which is similar, but with different representations of the paths due to having uniform access to nodes in the tree due to having id elements everywhere that matters), I would consider string diffs overengineering.

That's actually a pretty good idea!

That would be really useful for some things. Quite a burden to put on the library implementors though!

Let's say you want to update a typo in a lengthy document, I think it's worth the trouble. Good diff algorithm is hard, but there is open source solution.

http://code.google.com/p/google-diff-match-patch

That is a really great point in favor of using string based diff. You've convinced me that's a better way to go than editing JSON structures. (Especially if you have big strings containing JavaScript code and other fluffy stuff.) Also of course it's better if the JSON you're patching is already represented as unparsed text, or if you have an un-parsed backing store you can apply the diffs to.

Reply on news.ycombinator.com