Thanks a lot for you thoughtful comments. I indeed originally envisioned this "limited collaborative mode" as a quick and dirty hack that I can implement myself quickly enough to work on one specific project. Unfortunately I didn't know enough about networking in order to pull it through. In particular, I wasn't aware of the IM drawback you've mentioned.
Anyway, let me comment on the only issue I feel myself qualified to comment on: creation/deletion of pages. The whole idea of this "limited mode" is that collaboration happens on the level of layers, not documents, and not even pages. So, in the most basic form, every collaborator decides for themselves which layer to share with whom and which shared layer to use. But I envision two useful automatic modes: if collaborator A who is sharing layer n from the last page with collaborator B, creates a new page, then layer n on that page automatically gets shared with B as well. Correspondingly, if B who is incorporating layer n from page k, sees that layer n from page (k+1) becomes available, then he automatically creates a new page and attaches the new layer to it. Also, if A deletes a page that has a shared layers, then it automatically detaches and becomes the property of whoever it was shared with. I think these are useful defaults, but this is all debatable. The framework itself is extremely flexible. My initial idea was indeed to use something like libpurple, but I quickly dug myself into learning all various networking protocols and than a new academic year happened unexpectedly :) Thanks, --- Alex. On Tue, Apr 19, 2011 at 09:27:10PM -0700, Denis Auroux 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. ------------------------------------------------------------------------------ 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
