Web-based collaborative editor

[keyboard]

I have a php and jquery web-based file editor, that constantly updates the file you are working on (everytime you press a button).
The whole point is to allow multiple people to work on the same file at once, without overriding each others changes...
However, everytime you type, it updates the file, but if you both type at the same time, it wouldn't save one of the key changes...

So, I need to be able to add the text into the file, without re-writing the entire file...
Any thoughts?

[djr33]

Specifically, the time delay for saving by Ajax (that's how this is done, right?) is what is a concern, not that they'd literally type something at the same second.

You could look into how this is done in Google docs.

I imagine it's not the whole file that is rewritten. Instead, commands are sent back and forth between all users and the file is updated with information about cursor position and text changed. It would be complex to do all of that, but I can't really see another way.

One way it's clear that this is how Google docs works is that I think some of those documents are larger than would transfer quickly via Ajax.


There is an alternative, however... you could just hope they never overlap too much and only use the local copy (not sure how that works) rather than replacing what was just changed with the update (if it removes something that was just added by the user). Somehow that could result in hoping that the two users don't log off at exactly the same time and otherwise the changes would be saved. They'd be coordinated once the users stopped doing things at exactly the same second. But of course I guess this still runs into problems if they're trying to edit each other's work at the same time.

[keyboard]

Specifically, the time delay for saving by Ajax (that's how this is done, right?) is what is a concern, not that they'd literally type something at the same second.


Yep, although the number of keystrokes per second, it is always possible that they are hit at the same time (in milliseconds)...



There is an alternative, however... you could just hope they never overlap too much and only use the local copy (not sure how that works) rather than replacing what was just changed with the update (if it removes something that was just added by the user). Somehow that could result in hoping that the two users don't log off at exactly the same time and otherwise the changes would be saved. They'd be coordinated once the users stopped doing things at exactly the same second. But of course I guess this still runs into problems if they're trying to edit each other's work at the same time.


I don't really understand what you mean... could you elaborate?

I was thinking maybe you could keep a copy of the document before it is saved, then compare that to what they've written, then just send the changes, but I'm not sure how you'd do that...

[djr33]

I don't really understand what you mean... could you elaborate? Hm. My alternative idea isn't actually practical, I don't think. Basically I was imagining storing the text locally and then only updating the server when possible. But then you would eventually run into the original problems.
Some combination of that and storing individual commands (rather than the whole file) is probably the best option.


Edit: Actually.... here's how it should (or at least could) work. Don't store ANYTHING locally. Write an Ajax-interface serverside word processor. Complicated, but the result would be exactly what you need.
Of course I suppose you'd get delays if Ajax was slow for some reason, so you might want to have some sort of preview but that could then be misleading...

[keyboard]

Hm. My alternative idea isn't actually practical, I don't think. Basically I was imagining storing the text locally and then only updating the server when possible. But then you would eventually run into the original problems.
Some combination of that and storing individual commands (rather than the whole file) is probably the best option.


Edit: Actually.... here's how it should (or at least could) work. Don't store ANYTHING locally. Write an Ajax-interface serverside word processor. Complicated, but the result would be exactly what you need.
Of course I suppose you'd get delays if Ajax was slow for some reason, so you might want to have some sort of preview but that could then be misleading...

I don't understand what you mean in your edit... Ajax serverside word-processor?

[djr33]

Rather than relying on any browser functions at all (eg, a textarea), you would send all of the keyboard commands (events) directly to the server via ajax then load the resulting processed text on the screen as the result of that ajax call.
Complicated, but it would work and the server would always be synchronized.

[keyboard]

Ahhh, I understand now.
I get how you could send the keystrokes to the server, but how would you tell the server what to do with them? Where they go in the document, etc.
keyboard1333

[djr33]

That's why you'd need to forget all browser defaults. Capture key events using Javascript and go from there. Remember the cursor position, etc. It's a lot of work, but I think it would be effective.

A perfect system would combine that and a preview in the browser, but that just makes it more tricky.


If you want to think of this in another way, imagine how you could include an undo command (with several levels of undo). At some point it would just be too much to save a different copy of the whole document each time you go back a step. You'd actually want to save the individual key commands and truly undo what was done.



Remember, there are other options. I wouldn't want to take on this project at the moment. It's just a lot of work.
One option is to just use something like google docs (is there a way to embed google docs in a website yet?).
Another option would be to only allow one editor at a time. If you want a little more interaction than that, you could allow only one editor at a time per paragraph or some other unit of text. That way you'd avoid all of this trouble but wouldn't need to get into the complexities of two cursors chasing each other around.

[traq]

honestly, I've never understood why anyone would want two people typing one document at a time, anyway. Whiteboards, yes. Chats, yes. Docs? makes no sense to me, plus, -as Daniel says- complex.

If you want to do it, though, PHP might not be the best route. You might look into something like node.js, especially since it would be nice to tightly integrate with the client-side code.

[djr33]

If you want to do it, though, PHP might not be the best route. You might look into something like node.js, especially since it would be nice to tightly integrate with the client-side code. That's a really good point. I don't know how much it would solve the problems of two people overlapping and trying to get both to catch up, but it should be better than Ajax+PHP.

[traq]

well, node.js uses a single connection per user, which it keeps open for the lifetime ("streaming," as it were).
you could do exactly what you were discussing above: send input to the server (and on to other clients) on every keystroke.

[djr33]

My post wasn't clear. Technically, yes, that's fine. But it could still be a little confusing if two users have slow connections and are editing the same sentence, for example.
Assuming no connection delays, node.js would be perfect. And obviously there's nothing you can do about connection delays.

[traq]

ah, yes.