Hi everyone, This sounds like a great idea. We could even implement a ownership transfer of layers. For example, if I wanted to edit a stroke on my collaborator's layer, I could select one of his strokes and we could both agree to temporarily transfer ownership of the layer to me so I could recolour or resize it for example. My collaborator would be unable to edit his layer until I release control of it.
I'm not sure what happens to undo redo in this situation, but that should be minor. One idea is to disallow undos further than the tranfer of layer ownership I would be willing to work on implementing this feature if everyone else thinks it is a good way to move forward. Alexander, If you're interested in this as well, I'm sure we can split up the work. It's still a pretty large project, even with the read only layer implemtation. Matt On Apr 20, 2011, at 12:27 AM, Denis Auroux <aur...@math.mit.edu> wrote: > 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 ------------------------------------------------------------------------------ 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
