Hi Everyone, Quick progress update: I'm still reading through the Xournal++ code and progress is slow. I still haven't managed to compile it (ran into some autotools bugs), but I'm trying a new revision from SVN and hopefully I get more luck.
On the original topic of collaboration: I was speaking to a friend last night about the challenge of implementing undo/redo and page deletions and he had a pretty good idea to work around those challenges. Here's the idea: a. Observe that erasing simple strokes has no effect on collaboration, unless two people try to erase the same stroke at the same time. In this case, the server/master needs to ignore out the erase command that arrives later. We can do this by implementing UUIDs for each stroke and keeping the list synchronized between everyone. Use randomized UUIDs (as opposed to sequential ones) so we don't need to worry about two strokes writing at the same time and being assigned conflicting UUIDs. b. To implement undo/redo, use the undo/redo history option mentioned earlier by Denis. His idea is as follows: you can undo a command 5 steps back without undoing previous steps 1-4. Under this system, undo/redo is now really just a set of deletions/insertions of strokes. Since we no longer need to worry about the order in which undo/redo commands were issued or arrived at the server/master, it shouldn't be an issue anymore. c. To work around the page deletion issue, give one user an 'admin' privilege. If a regular user happens to write a stroke on a page while the 'admin' is in the process of deleting that page, then the page gets deleted and the user's writing is lost. This doesn't matter though, because the 'admin' actions take priority over the 'user' actions. Let me know how this sounds. I believe we might need to put a few changes in the existing xournal++ code. As far as I was able to see in my quick readover, there are no IDs assigned with stroke objects in xournal++. Please let me know if this is accurate. Matt On 04/19/2011 02:04 AM, Andreas Butti wrote: > Am 18.04.2011 17:45, schrieb Jonathan R Young: >> Hi - yes that is what I was thinking - basically build on the existing >> frameworks for collaboration, rather than build an application specific one. > Can you make an example which framework should be used? > (And why?) > >> BTW - I am an IT architect, rather than a hard core developer (although >> I occasionally dabble, and used to code years ago!) > Ok, then you can draw an UML component diagram or something like this=) > > > (I passed my apprentice as "Applikationsentwickler" successfully, and > I'm studying computer science, now in the 4th semester) > > Andreas >> Jonathan >> >> On 18/04/11 09:53, Bob McElrath wrote: >>> No I think he means to encode individual strokes into SVG and transmit them. >>> It's also then easy to synchronize just by looking at some stroke sequence >>> number, in case a client is disconnected. I think it's quite a good idea. >>> >>> FYI I just pulled the xournalpp source and it doesn't build, due to a >>> problem >>> with Settings.cpp. >>> >>> Andreas Butti [andreasbu...@gmail.com] wrote: >>>> This would be possible, but you cannot edit this again with Xournal. >>>> >>>> (SVG export is possible with copy paste or export in the current Xournal++) >>>> >>>> >>>> But I don't support DBUS or such a protocol at the moment. >>>> >>>> (And I won't, no time...) >>>> >>>> >>>> Andreas >>>> >>>> >>>> Am 18.04.2011 09:38, schrieb Jonathan R Young: >>>> >>>> I wonder if Xournal could offer/consume a DBUS / telepathy / tubes >>>> approach, perhaps using SVG as the transport format, so each >>>> completed >>>> stroke can be published in realtime, and other clients can consume >>>> that >>>> message and render it. >>> -- >>> Cheers, >>> Bob McElrath [ Heidelberg University, Theoretical Physics ] >>> >>> "If you're not failing every now and again, it's a sign you're not doing >>> anything very innovative." -- Woody Allen >> ------------------------------------------------------------------------------ >> 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 ------------------------------------------------------------------------------ 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