Hi, I'm Tomer Aberbach

Hi everyone!

My name is Tomer Aberbach. I’m originally from Israel, but moved to the New Jersey at the age of 7 and have lived in the US since then. I fluently speak both Hebrew and English!

I recently graduated from The College of New Jersey, where I majored in Computer Science and minored in Mathematics, this past December. I’ve always found programming language theory, compilers, and type theory interesting and explored these topics throughout my studies. The last book I finished reading was Programming in Haskell by Graham Hutton and I’m currently making my way through Types and Programming Languages by Benjamin Pierce.

I also recently started working full-time on the Google Docs Collaboration team, which works on the collaboration specific features of Google Docs, Sheets, and Slides (like the commenting feature, for example). I’m technically located at Google’s NYC office, but I’ve been to the office once because I started the same week Google started having all employees in North America work from home due to the coronavirus. My work is primarily full-stack web development and doesn’t pertain to programming language engineering, but I may try to switch to some other role at Google in the future that does involve programming languages!

I’m excited to learn more about programming languages and to meet interesting people by participating in this community. Feel free to reach out if you want to chat or have any questions!

Cheers,
Tomer Aberbach

4 Likes

Hi Tomer, it is very nice to have you here!
Your experience with Google Docs can be quite interesting for this community because one of the things we are discussing are web projectional editors which may support concurrent editing. So we have always praise Google Docs when we discuss that :slight_smile:

I am looking forward to a lot of interesting discussions!

Cheers,
Federico

Thanks for the warm welcome. I’m looking forward to the interesting discussions as well!

For anyone interested in how real-time collaborative editors like Google Docs work, I encourage them to read about operational transformation, which is the mechanism used to resolve conflicting user edits.

2 Likes

For anyone interested in how real-time collaborative editors like Google Docs work, I encourage them to read about operational transformation, which is the mechanism used to resolve conflicting user edits.

From what I understood, OT does not work in some cases without a central instance. In practice, this would be Offline clients. Did I understand this right? How does Google Docs solve this?

I’m not entirely sure I understand what you mean by “central instance”. Could you clarify?

I’m not entirely sure I understand what you mean by “central instance”. Could you clarify?

I heard in some conference video that OT can resolve all conflicts as long as there is one central instance/arbiter that gets all changes in a timely manner. As far as I understood, this would not work anymore if you had several disconnected instances that may re-connect at some point in the future.

More concretely: As long as everybody types online into the same document, and the server receives all the changes live, it can resolve conflicts (i.e. with “last change wins”, because we can assume the user sees the other change).

Can it work if users A, B, C all go offline, do lots of changes, and connect again?

I base most of my half-knowledge on this series of articles:

1 Like

I have only been working on Google Docs for a short time so feel free to take what I say with a grain of salt! I’m not an expert in OT by any means.

I believe you are right that there must be a central server that resolves the conflicts between editors. The editors cannot communicate with each other in a decentralized manner.

However, I don’t think it is true that the central server must receive all changes in a “timely manner”. If users A, B, and C each go offline and make lots of changes, then one of them must come back online first (or at least, their request to sync is received by the server first). Suppose this is user A. There have been no new changes sent to the server since user A went offline so user A’s changes can be persisted by the server without doing anything fancy. Suppose user B comes online next. User B sends their changes to the server and each change (a single “change” being as granular as was decided when the collaborative editor was built) is transformed against each of user A’s changes before being persisted by the server. I would consider it an implementation detail to decide how to update users A and B with the new state of the document (e.g. send the whole document down to each user because there were lots of changes to resolve or send down user A’s changes to user B and user B’s changes to user A to be transformed against the local changes). The same idea applies for when user C comes online.

I think this can actually be tested on Google Docs right now. Going offline in the web editor “locks” the document so that you cannot edit it, but you can still edit the document when you go offline on the Android app (not sure about the iOS app).

One last consideration: just because it technically works doesn’t mean it’s a good idea! How well this works depends on how granular the changes being transformed are and on if the transforms between changes were designed well. If you are building a collaborative editor and anticipate that users A, B, and C will do extensive offline work on the same document content (not on different document pages or presentation slides), then automatically resolving their changes would probably not yield any user’s expected results. I think providing some kind of merge conflict resolution UI would yield a much better user experience for that situation.