Cursor support

[Geoff Goodman]

Hi guys,

I've managed to get 0.7.0 (from npm) up and running (though it seems to hang my server pretty regularly.

I've gotten to the point where I need to figure out how I will do cursor syncing in my app, which is a multi-file code editor. Do you have any updates on how this is going and/or what your plans are insofar as how you intend to implement and package it via the API?

Of note: I'm using the json0 type and am not actually using the Context api.

Any ideas?

Love ShareJS.

Geoff

[Flolagale]

I don't think that cursor syncing is provided by sharejs for now. We developed something for our app micro.glark.io, you can have a look at the github repo https://github.com/Bluefinch/microglark.

Hope that helps.

[Aslak Hellesøy]

On Thursday, October 10, 2013 1:06:02 PM UTC+1, Flolagale wrote:

I don't think that cursor syncing is provided by sharejs for now. We developed something for our app micro.glark.io, you can have a look at the github repo https://github.com/Bluefinch/microglark.

Hope that helps.

Thanks for the pointer. I'm not sure I understand why cursor syncing belongs in sharejs in the first place. Isn't this purely an editor thing?

Each editor publishes the cursor coordinates to the server (over a separate channel) and the server broadcasts it back to everyone. The editor then paints those shadow cursors in the document.

I could implement this in https://github.com/share/share-codemirror

Thoughts?

Aslak

[Flolagale]

Agreed, it makes sense to handle the cursor/selection stuff on the editor side only.

[Wout Mertens]

Not quite - the operations that others send transform their cursor location as well as yours, and when a new client connects they have to be told about all the cursor positions, even for long-idle collaborators.

So while you can do this in the client, ShareJS already has the infrastructure in place to do this.

Wout.

--
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.

[aslak hellesoy]

On Thu, Oct 10, 2013 at 2:20 PM, Wout Mertens <wout.m...@gmail.com> wrote:

Not quite - the operations that others send transform their cursor location as well as yours, and when a new client connects they have to be told about all the cursor positions, even for long-idle collaborators.

So while you can do this in the client, ShareJS already has the infrastructure in place to do this.

There is still work to be done in share-codemirror - basically painting everyone else's cursor. Where should I start looking to get notifications about where other people's cursors are?

Aslak

[aslak hellesoy]

On Thu, Oct 10, 2013 at 2:26 PM, aslak hellesoy <aslak.h...@gmail.com> wrote:

On Thu, Oct 10, 2013 at 2:20 PM, Wout Mertens <wout.m...@gmail.com> wrote:

Not quite - the operations that others send transform their cursor location as well as yours, and when a new client connects they have to be told about all the cursor positions, even for long-idle collaborators.

So while you can do this in the client, ShareJS already has the infrastructure in place to do this.

There is still work to be done in share-codemirror - basically painting everyone else's cursor. Where should I start looking to get notifications about where other people's cursors are?

I just want to make sure we're talking about the same thing here. What I'm after is to display where everyone's _caret_ is. You know, the blinking horizontal bar ion the editor. Users can move this around the editor without typing anything. (Obviously it also moves when users type and modify the document).

Are you saying that ShareJS has infrastructure to keep track of where each user's _caret_ is? That sounds very strange to me. Moving caret around without typing isn't an edit operation, so this doesn't sound like it belongs in ShareJS to me.

When you talk about cursor, do you mean a logical position where the last edit happened in the Share doc? That's definitely different from the caret.

Aslak

[Wout Mertens]

On Oct 10, 2013, at 15:57 , aslak hellesoy <aslak.h...@gmail.com> wrote:

On Thu, Oct 10, 2013 at 2:26 PM, aslak hellesoy <aslak.h...@gmail.com> wrote:

On Thu, Oct 10, 2013 at 2:20 PM, Wout Mertens <wout.m...@gmail.com> wrote:
Not quite - the operations that others send transform their cursor location as well as yours, and when a new client connects they have to be told about all the cursor positions, even for long-idle collaborators.

So while you can do this in the client, ShareJS already has the infrastructure in place to do this.

There is still work to be done in share-codemirror - basically painting everyone else's cursor. Where should I start looking to get notifications about where other people's cursors are?

I just want to make sure we're talking about the same thing here. What I'm after is to display where everyone's _caret_ is. You know, the blinking horizontal bar ion the editor. Users can move this around the editor without typing anything. (Obviously it also moves when users type and modify the document).

Yes correct.

Are you saying that ShareJS has infrastructure to keep track of where each user's _caret_ is? That sounds very strange to me. Moving caret around without typing isn't an edit operation, so this doesn't sound like it belongs in ShareJS to me.

It has the infrastructure and roadmap to eventually be able to do that, yes. The caret movements are not part of the docs operations.

The idea is that you'll be able to ask ShareJS for a list of connected users and be notified of their caret movements.

Wout.

[aslak hellesoy]

Awesome. Is there anything on master right now that I can use or is this sitting on some other branch?

Aslak

 

Wout.

[Soroush Hat]

This one has support for cursors in Ace editor:

https://github.com/share/ShareJS/tree/cursors

[Aslak Hellesøy]

On Thursday, 10 October 2013 at 19:19, Soroush Hat wrote:

This one has support for cursors in Ace editor:

https://github.com/share/ShareJS/tree/cursors

Yes, but the branch is 6 months old and doesn't merge cleanly with master.

Aslak 

[Joseph Gentle]

Sorry I've ignored this thread for awhile.

Cursors & presence is the only feature still missing for 0.7 to get
released properly aside from some better documentation. (
https://github.com/share/ShareJS/wiki/0.7-Status )

The reason ShareJS needs to take care of this is because there's no
other way to find out who has a document open or send messages. And
its important that your cursor moves around when text is inserted /
deleted nearby. ShareJS could supply a way to communicate with other
clients who are subscribed to a document, but if we're going to do
that we may as well do cursors too. (Although the cursor information
will only be made available in the document object in sharejs - it'll
be up to editor frontends to actually display the cursors.)

I wish I'd implemented cursors in sharejs 0.6 back when it was easy.
The problem now is that we can have multiple sharejs servers, which
each have connected clients. If a server crashes, all the clients
connected to that server will need to have their cursors removed, and
we don't currently have any way to track that in livedb. (LiveDB
suddenly needs to be made aware of which servers are running and
notified when one disappears). I have architected a few different
variants of the code, but its still a bit of a pain. We'll get there.

-J

[Dmitry]

Hi Joseph,

What we did with etherpad (custom version with clustering support), is we had client timeouts for cursors. If the client have not received any message from a known user for some period of time, his cursor is removed from the UI. For a new user, a first cursor message from unknown user adds him to a local list of current users. Do you think this might work with ShareJS too? Of course if you want to provide a list of subscribed users as well, the code should be a bit more complex.

[Geoff Goodman]

In that vein, could redis's EXPIRE be used to simplify the process to a timeout-driven presence solution? If one server were to go down, then those users' disconnection notices would only get propagated N seconds later. Sounds like a simple tradeoff to me.

Geoff

[Dmitry]

With each db solution you need to think about how to manage and get the data from db. EXPIRE can be used on single keys, and you definitely don't want to store each user as a separate key and gather them with  KEYS doc:[id]:users:* call. 

[Geoff Goodman]

Ah good point. Then could the same thing not be done via lua scripting on a as-needed basis?

Sorted sets could be used instead to track persistence. A scripted command could be used to lazily expire timed-out users.

[Joseph Gentle]

I like the idea of using timeouts. Server crashes should be pretty
rare anyway (except in development when it doesn't matter). Also
browserchannel clients tell the server their old session ID when they
reconnect. If you're using browserchannel, we could automatically
ghost your presence from any sessions you had open. (Actually, you'll
usually reconnect to the same set of documents, so the client could be
made responsible for that. For any documents you don't reconnect to
your cursor can timeout normally).

That should be pretty easy to implment - a lot easier than some of the
hairbrained solutions I was imagining :D

-J