Hello, Thanks for sharing this idea!
* The idea of each layer having a unique owner at each time and being read-only for everyone else resembles something I suggested at some point as a limited collaborative mode, but you've fleshed out the details a bit more and quite nicely. I agree that this should be sufficient for most needs. I find the limitations a bit inelegant, so I haven't been too enthusiastic about it; but it is certainly much less troublesome in terms of conflicts, and easier to implement. Perhaps better to have a limited collaborative mode that works rather than a more ambitious one that never gets done. So, yes, if someone wants to implement this, I'm all in favor! (Note: you still have to decide who's allowed to create new pages -- perhaps everyone by default? -- and to delete pages -- perhaps an answer in the spirit of your proposal is that everyone can delete pages but they only disappear from the view of the person who deletes them, and they remain available to the others?). * You wrote: "run additional threads that update the contents" for handling the remote-controlled layers. In my opinion, threads are a bad idea even in this limited-conflict environment -- then you have to handle all sorts of potential race conditions, e.g. when the user decides to "detach" a layer while the network-listening thread is trying to update it. Contrary to a common belief, reading incoming network data is NOT a blocking operation, even on a standard blocking TCP socket -- at least if you're using the appropriate mechanism for listening (e.g. setting up a GTK+ callback for incoming data, which internally relies on select()/poll()) and willing to accumulate partially read messages into buffer space until there's a full message available to process. So there's no need for a separate thread, just a few event handlers. * Using an IM protocol for handshake, authentication, and going around firewalls: this is a very interesting idea, though it's not necessarily ideal for all collaboration settings. I find the idea slightly intrusive. As a user, I don't want to have to sign up for any particular IM system. But at the same time it's an elegant way of connecting the collaborators -- especially if we could make things work over a variety of IM networks. For instance, would we be able to use libpurple? (since it seems to be able to connect to pretty much every IM system out there...). One big drawback: as far as I know, most IM systems do not guarantee delivery of the messages sent through them, unlike a plain TCP socket. They might not even be a guarantee that the successive messages sent by a particular party in the chat room will arrive to everyone in the same order they were sent in (!). If one has to re-invent a whole TCP-like system for handling acknowledgements, re-sending missed packets, etc., it's going to be a major pain. Or do any IM protocols provide a public interface to something with the same delivery guarantees as a TCP socket? Whether the IM protocol is XML-based or not is irrelevant, since the internal messages between instances of xournal need not be in any format like that of the IM system in which the communication runs. Denis On 04/19/2011 07:54 PM, Alexander Shumakovitch wrote: > 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 -- Denis Auroux MIT Department of Mathematics aur...@math.mit.edu (on leave) and University of California, Berkeley aur...@math.berkeley.edu Department of Mathematics Tel: 510-642-4367 817 Evans Hall # 3840 Fax: 510-642-8204 Berkeley, CA 94720-3840 ------------------------------------------------------------------------------ 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
