And a copy to the mailing list...
-------- Original-Nachricht --------
My ideas about implementing collaboration (also see comments down in the
quote block):
Don't think about undo / redo, the implementation is still not stable on
single mode, you have no chance to get it working in multiusermode in
this state.
Don't think about user rights, you can do this later. Better think about
error handling, because there is really much to do...
First we need target which should be implemented:
Support for 2 - 30 users, much more makes no sense, this will not work
anyway, but it should be theoretical possible that a class works with
her teacher.
Network connection: If your in a local network there are no problem, but
if you're connect through the internet, or a class through wireless...
You have a really big time gap until there is an answer from the server etc.
It's not necessary to generate random UUIDs, if a client writes a stroke
the stroke is sent to the server, the server assigns the stroke an ID,
send this id as responde to sender and sends the stroke to all other
clients.
Really important is to think about a message protocol, even if you use a
framework or something, you need always to send messages, a simple but
realistic example:
1. Handshake: exchange version number etc. to check if they are
compatible, return: OK / FAIL and optional a message to display to the user.
2. Commands: A command should be built up with an ID (which command), A
length (how many data are sent with this command) and the data
3. Each command has also an answer which looks the same, also ID,
length, data.
The most important thing is that it's easy extensible, because in the
future there are may (hopefully;-)) a lot new functions in Xournal++.
First I would only implement one command: send stroke: so the only thing
you can do is drawing on the first page and send this thought the
network. If this is working you can extend this.
But there are a lot of problems you will have, e.g. multi threading and
synchronisation, so don't try to much at time.
And before you start: I'll provide you the necessary interface, you
don't have a chance to understand the complete Xournal++ code in a short
time, its more than 30'000 lines of code;-)
Am 19.04.2011 16:40, schrieb Matt Chan:
> Hi Everyone,
>
> Quick progress update: I'm still reading through the Xournal++ code
> and progress is slow. I still haven't managed to compile it (ran into
> some autotools bugs), but I'm trying a new revision from SVN and
> hopefully I get more luck.
If you have such problems copy the error message and send an email to
me, may I can help you.
I had a lot of problems, and still not all is working as it should (e.g.
there is a preview extraction tool, which is not built neither installed...)
>
> On the original topic of collaboration:
>
> I was speaking to a friend last night about the challenge of
> implementing undo/redo and page deletions and he had a pretty good
> idea to work around those challenges. Here's the idea:
>
> a. Observe that erasing simple strokes has no effect on collaboration,
> unless two people try to erase the same stroke at the same time. In
> this case, the server/master needs to ignore out the erase command
> that arrives later. We can do this by implementing UUIDs for each
> stroke and keeping the list synchronized between everyone. Use
> randomized UUIDs (as opposed to sequential ones) so we don't need to
> worry about two strokes writing at the same time and being assigned
> conflicting UUIDs.
>
> b. To implement undo/redo, use the undo/redo history option mentioned
> earlier by Denis. His idea is as follows: you can undo a command 5
> steps back without undoing previous steps 1-4. Under this system,
> undo/redo is now really just a set of deletions/insertions of strokes.
> Since we no longer need to worry about the order in which undo/redo
> commands were issued or arrived at the server/master, it shouldn't be
> an issue anymore.
This is may possible but may not. Example (1: first done, 5: last done)
1. Write a stroke #56
2 - 4: do something else
5: set the color of a selection, which also contains stroke #56
if you now undo action 1 and later action 5 Xournal will crash... I know
what I'm talking about, I had this problem;-)
>
> c. To work around the page deletion issue, give one user an 'admin'
> privilege. If a regular user happens to write a stroke on a page while
> the 'admin' is in the process of deleting that page, then the page
> gets deleted and the user's writing is lost. This doesn't matter
> though, because the 'admin' actions take priority over the 'user'
> actions.
Do it easy for the first release: all commands to deleted pages are not
handled
>
> Let me know how this sounds. I believe we might need to put a few
> changes in the existing xournal++ code. As far as I was able to see in
> my quick readover, there are no IDs assigned with stroke objects in
> xournal++. Please let me know if this is accurate.
No, there are no IDs, there are also not everywhere listener
implementations where you need them, but this is not a problem, this is
easy to add.
>
> Matt
Andreas
