Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Implement metadata: active sessions, cursor etc #24

defunkt opened this Issue Aug 9, 2011 · 20 comments


None yet

defunkt commented Aug 9, 2011

Maybe this is the wrong way to think about ShareJS, but is there a way to get a list of currently active sessions (potentially with metadata)?

I'd love to implement something like this:


josephg commented Aug 10, 2011

I really want something like that too, along with cursor positions. (Which are more fiddly, because everyone else's cursors need to be pushed+pulled by your changes as well.)

I'm planning on making documents contain extra (not persisted) state, which clients can view and edit. That might be good for active session data too. Documents currently have a meta: field - thats probably the best place for it.


josephg commented Sep 19, 2011

I've written up a draft design doc for this feature:


defunkt commented Oct 3, 2011


Did anything along these lines ever get fully implemented? I see that there are scatterings of the meta object throughout the server code, but I don't seem to be receiving any of the info on the client side with the current Socket.IO client. I did notice that there is a BrowerChannel implementation underway as well, but I couldn't find any examples (or find in the code) any implementation of a BCSocket-based client...

So: a) Is it still on the roadmap to implement the meta object for the socket.io client (or did I miss it?), or is BC going to be the only client receiving new features going forward, and b) is there any sort of high-level API client running on BC yet (or any plans to write one in the near future), or are we pretty much on our own writing things like socket.send({p: oi: })?


josephg commented Jan 16, 2012

I would love to do all this stuff.

Locally, I have a working version of sharejs running on top of browserchannel. Another option is sock.js (which is another socket.io -style library, written by some vmware guys).

As you see, I have a design doc for how I want to implement metadata ops. I was waiting for the refactor of the model code (which is done now).

Unfortunately, I haven't been working on sharejs lately because I really like having enough money to eat. I'd keep working on sharejs if I could get sponsorship for it. Otherwise, the project is at the mercy of people brave enough to send pull requests.

@defunkt - Would github be keen to help out?

I certainly hear you on the needing to eat :-) I wish I worked for an awesome company like Github that could offer sponsorship, but alas I am just a founder working on a startup.

I read on the mailing list that you were planning on switching from Socket.IO over to your BrowerChannel implementation going forward. Sounds good, I will just wait patiently for a ShareJS client built on top of that, then, I know you're probably plenty busy! Great project, by the way, definitely the best thing out there for real-time collaboration apps.


mcolyer commented May 21, 2012

@josephg I'm interested in having this feature as well and might be able to implement it. Before starting to tackle it though I wanted to make sure 1) you weren't actively working on it and 2) make sure that https://github.com/josephg/ShareJS/wiki/Document-Metadata was still your current thinking of how it should be done.


daredevildave commented May 21, 2012

@mcolyer Check out the meta branch, Joseph has just accepted my pull request which includes updating the client-side metadata document with session data.


wmertens commented Aug 7, 2012

I closed the cursor request to keep the discussion here where it belongs. We need to come up with an implementable API.

@nornagon said:

I think the best way to do metadata would be to allow the user to define an arbitrary JSON object to use as metadata, and then they can define a transform function (Doc, Op, Metadata) -> Metadata'. We could provide a default transform function for transforming a set of cursors/selections on a text document, and people who want to do more complicated things can just provide a different transforming function.

There also needs to be APIs to set/update metadata directly (e.g. when user moves cursor), and the user should also provide a function from Metadata -> JSON object describing what needs to be stored in the database.

@wmertens said

The transform for cursor positions is a good idea, otherwise any insert will cause a flurry of cursor updates.

Maybe the metadata should have persistent and non-persistent sections? Changes to persistent data get stored in the db immediately. Last writer wins. No functions needed.


luto commented May 12, 2013

What relation has this to model.applyMetaOp() and the meta-argument of model.create? Is there documentation on this somewhere?


josephg commented May 12, 2013

Thats the start of an implementation of this feature.


dignifiedquire commented Sep 30, 2013

@josephg what's the current state of this? Do you have a spec how you want this to be implemented in 0.7? Anything started yet?


josephg commented Sep 30, 2013

I've got a bunch of changes sitting in a git stash. The problem is figuring out how cursor / presence data is maintained & updated if one of the servers running livedb crashes. I know exactly how I want the rest of the logic to work (and I have it somewhat done). Its just the livedb changes that are causing me grief.

Do you want to chat about it over skype sometime? I'm josephgentle


dignifiedquire commented Sep 30, 2013

Sure would love to talk about it. Though it'll be a bit tricky because if the time difference (I'm in Germany) I'll ping you on skype

@josephg josephg closed this Oct 1, 2013

@josephg josephg reopened this Oct 1, 2013


devongovett commented Jan 19, 2014

Any updates on this?

@josephg Would be awesome just to have the changes you mentioned in a branch somewhere so others can help. Or is this not how you would like to implement this feature now?


josephg commented Mar 1, 2014

There's a lot of changes to make to this feature. I want to do it too - I've just been busy. I'll put out an update soon.


devongovett commented Mar 1, 2014

Glad to hear it! We're currently working on handling presence with a separate system, but it would probably be better done by ShareJS since it already knows what documents clients are subscribed to. As for cursors, I almost think its more of a UI level problem that each editor needs to solve independently.

Cursors are different for each type of document, and clients might need additional info about the cursors besides their position. For example, we make each cursor a different color, and its nice to make the colors match for all users so they can say "oh I'm red, you're blue right?" and have it make sense. I'm not sure how much metadata you want to sync in ShareJS (arbitrary?), but I'd imagine it could vary widely from application to application.

We thought about making session and cursor info just part of our JSON document structure, but didn't like having to store that ephemeral data in the database, especially with the extra operations created for cursor movement. Our current solution is to let each client manage the list of active sessions separately, using a local timeout on each to remove them when they don't send an operation for a certain amount of time. The server also maintains a list of connected clients with a matching timeout. That list is sent to new clients when they connect.

Let me know if you need help with this feature, I'd love to see it implemented in ShareJS! :)


dignifiedquire commented Mar 20, 2014

@josephg I'm in big need for that feature any chance you could give us some info on what you already did, what we can do? I could get a week of full time development on that feature if you can give me some pointers, let me know what your plans are.

Has any progress been made on this? I would also be interested in helping out with this feature.

coxley commented Aug 6, 2015


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment