GSoC proposal: collaborative editor

[Mikhail Krishtop]

2012/3/21 Othmane Moustaouda <othmane.moustaouda at gmail.com>

> Hi!
>
> From mailing list I have known that I have a "concurrent", good! A
> little bit of competition will encourages both us to pull out the
> best! :D
>
> Returning to the project, after reading documents and after some
> investigations now I have clearer ideas about how to implement it:
> since is a plain text editor I have to focus only on the text content,
> omitting details like font size, font type ecc., so I thought that
> should be possible to manage the text's changes through a mechanism
> based on diffs, i.e. each time an user makes a change to the shared
> text, a diff will be generated and shared to all other participants.
>
> In order to make this possible, in my vision, something like a
> checksum is needed, to ensure that all participants are working on the
> same text. Another key point is that one of participants must act as a
> "central node", why? Because if, for example, due to a network issue,
> one or more participants have a different version, what is the right
> version on which to base the different others? Is the one hosted by
> the participant that is acting as central node. Who can play this role
> can be, for example, who has started the collaboration, or maybe
> better, who has the fastest connection.
>
> All these informations will be transmitted via a D-Bus Tube, I thought
> that for this case a D-Bus Tube is more convenient for use than a
> Stream Tube as it offers the possibility to handle events via signals
> (for example an user login or logout, or a text modify).
>
> About the diff part, since Qt doesn't offer something for generating a
> diff between two strings, I have to use some kind of library that
> offers a diff algorithm, searching I found  a very few of interesting
> things, one of them is this (
> http://code.google.com/p/google-diff-match-patch/ ) a very nice
> library! I thought that maybe is better using a well known library
> available already packaged?
>
> I made an initial UI draft, it's very basic, something like a starting
> point
> http://dl.dropbox.com/u/61029609/ui_draft1.png
> a little graphical detail (adopted by almost collaborative editors)
> could be that each participant will have its own color and every
> addition made by him will have that color as background.
>
> Surely I wrote something stupid, let me know please! :D
>
>
> Othmane
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
>

Hi, Othmane!

I'm glad to know I'm not alone in this kind of research :)

But, unfortunately, I see some disadvantages of your methods. Finding diffs
in strings is a good idea, but until you work only with simple text
information (or it would be something big like git). Also because this you
need to know what is the right version of a document and need to apply
client-server based architecture.

I want to offer other proposal. In this kind of situation (when we have
possibility of massive collisions) i think it would be appropriate take a
look on the DB architecture. In my project every action of the users would
be a transaction. Each transaction would have the exactly time and simple
(atom) sequence of action (likewise "create document", "add character a",
"users 1 cursor go to left"). In that way I can manipulate any kind of
date, not only the text. Owerview <http://dl.dropbox.com/u/10671824/im1.png>

Take a look on the collision
detection<http://dl.dropbox.com/u/10671824/im2.png>.
Every client send his own transaction to other clients and receive
transactions from other clients. If time in received transaction is grater
then in the last transaction in transaction list, then the last transaction
undo and time compares in received and second from the tail. When program
find right place for received transaction it just applies needed action of
this transaction and redo all cancelled transactions.

In this way I get rid from the server, because all of the clients know what
and when  has been done. Plus I can extend my text editor in somethig big
like a basket in the future.

I think in the first I must choose right architecture for the program and
in the second - implementation details. For this purpose I already start
writing some prototype on the Qt and, I hope, I can represent it to you,
guys, in just a couple of days. :)

Good luck!
Mikhail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20120321/6e4b6b62/attachment.html>