accessing version history (for read-only timeslider functionality)

[Ari Bader-Natal]

I've been building a web application using the old Etherpad codebase (http://sketchpad.cc), and am interested to see if I could build a stripped-down version of this application using ShareJS. I'm impressed by how straightforward the example applications seem to be to create, and would love to try to build something myself. One thing I haven't seen how to do is (read-only) access to arbitrary revisions of a document. Is there a way to do this? 

The Etherpad read-only view provides a "time-slider" that lets you scrub through back-and-forth through the revision history of a document, applying the necessary transformations without reloading the entire contents of the document. I'm not looking for a UI for this, but just JS control: Render revision 28, apply transformation to render revision 13. Is this possible with ShareJS? 

Thanks, 

Ari

[crypticswarm]

https://github.com/josephg/ShareJS/issues/63

[crypticswarm]

https://github.com/josephg/ShareJS/issues/12

[Andrew Mao]

I'm curious about this as well. Is there an efficient way to play doc revisions both forward and backward? I need to view this in a web app as well

Could you follow up with how you implemented this...is it in ShareJS or something completely different?

[Joseph Gentle]

Using the JSON type or the text0 type, operations are invertable -
which means that if you have an operation deleting some characters,
you can invert the operation and re-apply it to put the characters
back.

The API that the client exposes doesn't provide time slider
functionality, but it would be pretty easy to add. The backend exposes
a getOps API which needs to be plumbed through to the client. To go
backwards, just invert&apply. To go forward, apply. The hard thing is
weaving that through the doc class - obviously you don't want to
actually submit those operations to the server or you'll reverse time
for everyone.

-J

> --
> You received this message because you are subscribed to the Google Groups
> "ShareJS" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sharejs+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Andrew Mao]

For future reference to others, a follow up to a question I posted on the issue: https://github.com/share/ShareJS/issues/12#issuecomment-21962646

If I am using redis as a datastore for ShareJS, does it store all the ops starting from version 0, or does it combine ops into snapshots for faster playback later?
The latter would clearly be faster from an implementation perspective but would cause history to be lost and not be viewable. I guess the optimal implementation would be to store occasional snapshots along with all ops which would allow any revision to be accessed in O(log n) time and O(log n) space...but not sure if that's what you guys did.

 J replied:

It stores every op starting at version 0. And yeah - if you want to be able to efficiently see any version, keyframes is the right answer. But if you don't want them, they will blow out your database size significantly.

[Geoff Goodman]

On the subject of replaying ops, what has worked for me is to make a copy of the snapshot and then apply inverted ops to that copy independently of the doc (instance).

A very limited example is in: http://plnkr.co/edit/Fzj4LZe4iF3vGlKohpTq

In that, I pulled json0.js from the ottypes repo (which includes the invertible text0 type) and messed around with manually applying ops to snapshots. I would not recommend trying to patch this through sharejs' Document class... just stick to ops.

Geoff

[Curran Kelleher]

Also related:

• https://github.com/josephg/ShareJS/issues/12 API for history management
  
• https://github.com/share/sharedb/issues/45 Fetch snapshot of previous version