Hi Matt, I gave a lot of thought to collaborative editing a while ago, because I wanted it done *right*, i.e. in a manner that is robust with respect to network lags, disconnects/reconnects, etc. (which are likely since a lot of tablet users are highly mobile and might move between network access points while working), and allows each collaborator to undo their changes independently of each other.
It turned out to be too big a project given my available time and the preliminary need for a serious code rewrite before anything could be done. With xournalpp's much cleaner architecture, it's still a big project, but might be more doable. I tried to summarize my thoughts on the question, and a proposed in a May 2010 thread on this mailing list, more specifically the message http://sourceforge.net/mailarchive/message.php?msg_id=25270238 which I encourage you to look at. (Andreas as well, unless I've already spammed you with this: while this probably goes way beyond the scope of what you want to be doing for now, some of the structural constraints discussed in there might be of interest to you, in case they agree with design decisions you have been considering for xournalpp). In terms of the theory of collaborative editing my views haven't changed since that May 2010 message. In terms of the practice, a few comments: - no point in trying to do this with old-xournal, its code is not written appropriately to make this easily implementable. - probably best to wait for Andreas to have reached a point where the code of xournalpp doesn't change too much anymore before doing real serious work. In any case, at this point it's certainly up to Andreas to decide whether he's ok with someone else working simultaneously on his code and to what extent. (But my impression is that it'd make sense to wait more, since xournalpp's code still seems to be evolving very fast.) - it is probably worth taking a look at the structure of xournalpp in the context of future networking plans, to see if any changes would be desirable at this stage. (For example, would some tweaking make it easier to perform actions on the journal initiated by a network message rather than by the local user? How about the other issues I pointed out concerning the architecture of old-xournal?) - while I'd love to end up with an elegant and powerful collaboration mechanism, I'm realistically not going to be the one doing it, and whoever does it gets to choose how it gets done. This is important enough that careful thinking should be required before moving on to any implementation, but you should feel free to disagree with my opinions on the question. All that matters in the end is that things work in a way that's reliable and user-friendly. If it means some reasonable restrictions on what can or can't be done simultaneously by the collaborators, so be it. - finally, while I don't want to discourage any volunteers, I'd like to reiterate that this is not an easy thing to implement. I don't think much GTK+/UI familiarity is required, but it requires at least: a careful study and good understanding of the inner workings of xournal/xournalpp; experience with network programming (understanding at least the general principles and the constraints that arise, the actual handshake and messaging code can probably be outsourced to someone else if needed); experience with code that handles complex data (the interaction of real-time local user operations with networking is more challenging than one might imagine at first, and undo-redo adds a whole other layer of complexity, see my post referenced above). Denis On 04/17/2011 06:40 PM, Matt Chan wrote: > Hi, > > I've been reading up on the xournal++ changes lately and I've been > impressed. I'm not sure whether this would be better posed to Andreas, > Denis, or anyone else, but I'm interested in adding collaborative > functionality to xournal (and getting some C++ practice before I start > my M. Sc in September). > > I have wanted to write up a collaborative notepad program ever since I > tried to ask a calculus question to a friend over skype and couldn't > draw a graph. I've looked at Xournal before, but I wasn't aware of what > kind of changes would need to be made to implement collaborative > functionality. > > Since the xournal++ effort is underway and my undergrad requirements are > complete, I thought it might be a good time for me to get cracking on > putting this together. > > Just a disclaimer: I'm sorely out of coding practice and lacking in > experience. I did my undergrad in chem/comp sci, but I've been taking > algorithms courses for the past few years. I've also never touched GTK+ > and I've only used Qt for a few hours. Finally, I've only collaborated > with other people on a large programming project once, and we worked > together in person. I may need a bit of hand-holding or have stupid > questions. I hope people are willing to put up with me for a bit. > > I have a couple of questions before I start: > > 1) What code should I start working from? It seems that the xournal++ > trunk is actively changing, and I'd like not to write code that depends > on a function only to find out it disappeared later on. > > 2) What kind of vision does everyone else have when they think of > collaborative xournal? I'm interested in features and infrastructure > requirements specifically. I'll use this information to try and figure > out some kind of implementation that satisfies this. > > Thanks for your time. I hope that something great comes of this. > > Matt > > ------------------------------------------------------------------------------ > 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 aur...@math.berkeley.edu University of California, Berkeley Tel: 510-642-4367 Department of Mathematics Fax: 510-642-8204 817 Evans Hall # 3840 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
