Hello all, I've just subscribed to this mailing list and am not able to directly reply to the previous thread about collaboration in Xournal. Sorry.
I was thinking about the easiest way to implement collaboration in Xournal a while ago and came up with a plan on how to do this in a way that 1) doesn't require big modifications to the existing code and 2) avoids all the issues with synchronization, Internet lag and so on. The idea is to utilize the existing infrastructure of layers. Here is how the process would work: collaborator A(lice) makes one or more layers from the page she is working on, available to selected people (more on implementation of this below). Her collaborator B(ob) sees that A made some layers available for him for viewing and incorporates them into his own page (most probably, below layers he is working on). These layer(s) are available for B read-only, but he sees every change that A makes. At the same time, B can make his working layer available to A so that she incorporates it into her own page. A and B can exchange the ownership of every shared layer at any moment. It should also be possible to "detach" the read-only layer and make it your own (before saving into a file, for example). This would destroy the synchronization between two copies of the layer though. What this scheme achieves is that for every shared layer there exists exactly one collaborator who can modify it, and this collaborator works on this layer _locally_. All other collaborators can look but don't change. But since layers are stacked on top of each other, they will see a superposition of shared layers and their own writing --- exactly what is needed. In fact, this matches the way I usually work with my collaborators on the same piece of paper: I never cross out what the other has written, but often write on top of it. Advantages of this scheme: 1) Easy to incorporate into existing structure. Basically, one needs to allow layers to be read-only and to run additional threads that are going to update their content. 2) Each layer is edited only locally. There might be a delay with showing the result of the changes to a remote collaborator, but not on the computer where the editing is done. 3) Easily scalable to any number of collaborators. Possible disadvantages: 1) Not easy to resume synchronous collaboration after a break (when the document was saved on both ends). One solution could be to keep a checksum with each layer and if checksums for a certain layer match on both ends, then propose to collaborators to decide who is going to edit it. At the end, it would be up to humans to decide which layers to share and how. 2) Not possible to edit the same thing on both sides. Is this really needed? 3) ???? Now, concerning the issue of authentication and sharing of the data. I believe that the easiest solution would be to use the existing IM infrastructure. Almost everyone nowadays has an account with at least one IM network and there are plenty of software/libraries that implement interconnections between them. These existing software can handle authentication. In particular, take care of such issues as making some content (layers) available to other participants of the network. Moreover, the existing XMPP protocol (used by Jabber and others) is based on XML, so I think it should not be overly complicated to incorporate Xournal primitives into it. The data would be shared stroke-by-stroke. I guess this should result in a reasonable latency, especially considering that communication for each layer would be unidirectional. I'm not any specialist in Internet protocols though. Oh, and using existing IM infrastructure would eliminate the need for distinguishing between servers and clients and avoid problems of having computers behind firewalls (most of those used at home are). So what do you think? Does this all make sense? Thanks for your attention, --- Alex. ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Xournal-devel mailing list Xournal-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xournal-devel
