Supporting of rfc6902 specification for JSON type?

[skotchio]

Do you plan to create ottype for supporting of JavaScript Object Notation (rfc6902 JSON) Patch specification?

[josephg]

This was brought up in the discussion of the new json type (which will replace json0). The json0 type doesn't support moving objects between paths, so its not compatible with json patch.

The new OT type won't use json-patch operations internally, but the new json type's operations will be almost isomorphic. When its done, it might be worth writing couple of functions to convert operations back and forth for interoperability.

Do you know if the json patch specification is used anywhere yet?

[skotchio]

There is a lot of implementations for jsonpatch specification for like the following:

https://github.com/Starcounter-Jack/JSON-Patch https://github.com/bruth/jsonpatch-js https://github.com/fge/json-patch https://github.com/stefankoegl/python-json-patch https://github.com/mikemccabe/json-patch-php

It actively used in Pyhton, Rails, NodeJS, PHP communities. Also there is service that provide building real-time cloud applications based on jsonpatch http://rocket.github.io/

I think you could explore using of jsonpatch as primary approach in your json1 version because it's popular and has big community.

[josephg]

Great thanks - good to know. I haven't heard a lot of people talking about it, but I might not be reading the right blogs. I'll definitely either implement the bridge myself or get someone else to write it.

Like json0, json1 documents will allow you to embed data thats governed by other OT types inside it. The canonical example is rich text. This is really important because the semantics of conflicts in rich text document operations is different from any of the semantics which the json type has. To make this work, JSON operations will be able to contain rich text editing operations as opaque structures tagged with 'this is a rich text edit'. This makes bridging operations with embedded types hard / impossible.

I really like the idea of the JSON type being used by lots of other projects. If you don't need embedded types, it should work great. However, sharejs will probably not use jsonpatch operations as first-class citizens because of the embedded data structures.

[skotchio]

@josephg I totally agree with you and understand your purposes.

I'm using jsonpatch because my client-side's document is engined by Backbone nested Model. So, json representation on server-side is reflection of Backbone.Model on client-side and I've written custom jsonpatch operations like 'add', 'move' etc. for Backbone structure to be the same.

I'm developing web applications like GoogleDocs and maybe I'll use rich text in a future but now I'm using Backbone on client-side.

The main drawback of the jsonpatch is the lack of OT and thought you could bring this one by implementing in new version version on json1.

[josephg]

So long as you're not embedding rich text or something like it, using json1 might be a great way for you to add OT to your system. The bridge will probably be a simple set of opToPatch and patchToOp functions.

[skotchio]

Thanks. I'm very excited of new json1. Do you plan approximate release date?

[josephg]

No. Whenever I plan a release date and that date slips, I feel guilty. So I don't want to commit to any given date. I am moving back to Australia in 1 month, and I'm trying to figure out what I'm going to do next year. The amount of work left in json1 is unknown, and the amount of time I have to work on it is unknown.

It'll probably take at least 2 more weeks. I cannot be more specific than that.

[skotchio]

@josephg I want to thanks you for the great work and good luck!

[josephg]

Thanks :)

I got transform working for object-move today. Now its just a case of adding back all the other features. Do you know if there's a mailing list or something for the json-patch spec that I can announce this at when its done?

[skotchio]

Great! The only mailing list I know is https://groups.google.com/forum/#!forum/json-schema. There are a lot of posts about several specs including JSONPatch https://groups.google.com/forum/#!topic/json-schema/5jCPq7W80Jg

[shanewholloway]

Thanks for working on adding OT support for JSON Patch. It is fantastic to see a standard emerge, and even better to have operational-transform implementation from an OT veteran.

Have you considered publishing separate OT implementations for non-nested variants of list and hash? The functionality is obviously a subset of what you are doing here with JSON patch. However, the simpler constrained implementations would make useful secondary examples of how to implement OT types, and from a learning perspective it helps to have 2+ simpler examples. And perhaps the constrained implementation could approach the O(N+M) complexity achieved with text.

It is additional nontrivial work, those learners who follow after you will have (even more) gold to read! Thanks for your work! -Shane

[gaurav21r]

@josephg Absolutely great work on this project! I'm not asking for a status per se on json1 :stuck_out_tongue: Just wanted to know if it is still in your plans. More importantly, since you were mentioning some work on object move, maybe you could release a public repo? I'm sure some of us can think to contribute once a repo is in place?

[josephg]

Yeah its in a public repo at josephg/json1

I've been writing about the process on the sharejs mailing list - should we have a mailing list for JSON OT?

[gaurav21r]

@josephg Oops sorry my bad. I think it depends on volume of communication? I think ShareJS mailing list alone is also fine, but I think you need to communicates this in JSON OT README.md?

I'm all for an ottypes mailing list as well which can discuss text0, json0 and json1

[josephg]

It took me a few years to get everything working, and its still not 100% ready. But the new JSON1 type is here. Now is the time to add JSON patch support if you want it - maybe file an issue in the json1 repo to get the ball rolling about json patch support if its still important to you