SoC 2006/Conflict Assessment
From AbiWiki
// Formalities Name: Mark Gilbert Time: ~40 hrs a week for 11 weeks, ~10-20 hours a week the following 4 weeks. Please list jobs, summer classes, and/or vacations that you'll need to work around: If I get this grant, it will be my job. Period. Any other activity, of which I have none planned, will have to work around it. Though I might work on improving my Russian fluency by night if things go really well with the project and I have the time. Have you applied (or plan to apply) for any other 2006 Summer of Code projects? If so, which ones? None. I thought about other cool projects and ended up spending all my time researching this one and how I would accomplish it. I think it'll be an awesome project to work on. What school do you attend? How many years have you attended there? Georgia Institute of Technology, 2 calendar years or 3 school years. What is your specialty/major at the school? Well, Physics, for now... Any professional/resume or personal/blog URLs you would like to list? I uploaded a partial CV for google which I listed in the signup profile thingy. The abisource mentors already know enough about me considering one of them reminded me of things to put on there (-: My background as it pertains to this proposal is in the proposal file. // The body of the proposal is in the link because when I pasted it here, I discovered that the limit is 7500 characters where I thought it was 7500 words, and I was far too detailed in describing my proposal and its execution to fit in that space.
Framework of mechanisms and algorithms for robust conflict assessment and resolution in live and/or multisession collaboration
Abstract: The proposal herein is essentially a two-sided framework of AbiWord mechanisms and AbiCollab plugin algorithms that facilitates a certain collaborative editing paradigm characterized by integration of all operative facilities. It is divided into two most-basic sides. The first, a visual communication infrastructure that lets the user know what's going on with respect to conflicts and concurrency in the collaborative editing session of all active editors. The second, a conflict prediction, resolution, and indication algorithm framework that works for many simple cases and lays the groundwork for a full-blown Delta Component Semantic Dependency Classification Scheme, facilitating streamlined productivity in fully-involved collaborative editing sessions by minimizing time spent fixing session syncronizations and duplicating the work of others.
Benefits brief: - Visual indicators give each user a better idea of what the others are up to when live and in-sync, while algorithms minimize the amount of time each user spends syncronizing their document, especially after extended periods out of sync and also if concurrently but non-simultaneously stepping on toes content-wise. - For concurrent disparate insertions, conflict prediction both informs users to minimize wasted time from duplicated work and informs the resolution algorithm of probable similarity (in which case, one is decided upon and/or their relationship is highlighted or annotated on-screen) or probable disagreement (in which case, the two are presented as insertion and deletion of one's own and the other respectively). - For edits/overwrites, conflict resolution decides on overall-agreeing changes and presents changes that are in disagreement. - For intersession syncronization, conflict resolution makes updates and filters changes that don't need to be prompted about (simply giving them each a revision with descriptive id) while presenting changes that seem to truly conflict (e.g. replacing a chunk of text with two totally different ones) as if concurrent. Equivalencies may be one or the other depending on preference. - Annotations are used both by humans to simply make comments about specific areas of text and automatically by the conflict prediction and resolution algorithms to explain what was computed, what was done (if anything), and what the remaining options are (including manual editing). - Annotations have various properties and operations that allow them to be colored by owner, arrayed, window-shaded (minimized), hidden en mass, edited (by owner), etc. Subsequent developments may allow threaded responses to be presented as such (like conversational dialogues). - Merging of uncollaborative documents takes advantage of the delta filtering code as well. - Combinations of features perform ideally with span inserts but handle edits robustly and overwrites adequately, always attempting to reduce user's time spent but never by risking making things worse. - The ultimate goal of all of this is to maximize productivity by minimizing time spent syncronizing and work-duplicating.
Please continue reading on the link to further information. I apologize for the fragmentation in this process - it's getting annoying for me as well, but I hope my project makes it worthwhile for both sides of the table. Cheers!
