A Collaborative Writing Mode for Avoiding Blind Modifications Center for E-Business Technology Seoul...
-
Upload
horatio-washington -
Category
Documents
-
view
214 -
download
0
Transcript of A Collaborative Writing Mode for Avoiding Blind Modifications Center for E-Business Technology Seoul...
A Collaborative Writing Mode for A Collaborative Writing Mode for Avoiding Blind ModificationsAvoiding Blind Modifications
Center for E-Business TechnologySeoul National University
Seoul, Korea
Nam, Kwang-hyun
Intelligent Database Systems LabSchool of Computer Science & EngineeringSeoul National University, Seoul, Korea
Claudia-Lavinia Ignat, G´erald Oster, Pascal Molli and Hala Skaf-Molli
Nancy-Universit´e, LORIA-INRIA Lorraine Campus ScientifiqueFrance
9th International Workshop on Collaborative Editing Systems (IWCES), 2007
Copyright 2009 by CEBT
ContentsContents
Introduction
Motivating Example
Our approach
Revisiting Motivating Example
View user interface
Conclusions and Future Work
Discussion
IDS Lab Seminar - 2
Copyright 2009 by CEBT
Collaborative EditingCollaborative Editing
IDS Lab Seminar - 3
Blind modification
When user modify a document without being aware of concurrent changes
Copyright 2009 by CEBT
Synchronous/Asynchronous Work Synchronous/Asynchronous Work ModesModes
Synchronous editing
Reduces conflicts and task completion times
Disadvantage
– no support for work in isolation
Asynchronous editing
Support for work in isolation
Workspace copies kept in consistent states
Risk of blind modifications
– Useless work
– Redundant work
IDS Lab Seminar - 4
Copyright 2009 by CEBT
Main IssueMain Issue
How to allow
Work in isolation?
Avoid blind modifications?
Our proposition
Provide information in real-time about group activities
Deal with trade-off awareness/privacy
Annotate the document with uncommitted changes
IDS Lab Seminar - 5
Copyright 2009 by CEBT
Motivating ExampleMotivating Example
Actions User1 Actions User2 Actions User3
Removes method isReal
updates method isReal
creates test class IntegerTest
IDS Lab Seminar - 6
Copyright 2009 by CEBT
Scenario with standard VCS Scenario with standard VCS
Step
Actions User1 Actions User2 Actions User3
1 op1= removes method isReal
op2= updates method isReal
op3= creates test class IntegerTest
2 COMMIT
3 UPDATE (conflict op1 ↔ op2)
UPDATE (IntegerTest does not compile)
4 Reinsert new method isReal
Remove test for isReal
5 COMMIT
6 UPDATE & COMMIT (no test for isReal)
7 UPDATE UPDATE IDS Lab Seminar - 7
Useless workSide effects
Useless workSide effects
Re-execution ofown changes
Re-execution ofown changes
Useless workIncomplete task
Useless workIncomplete task
Copyright 2009 by CEBT
User can perform…User can perform…
Modifies a document by generating operations that are immediately applied on his local copy
Makes available his local changes to other users by committing his local operations to the repository
If some non-integrated remote operations are available on the repository, the user is not allowed to commit local operation.
Updates his local copy of a document by integrating remote operations from the repository
IDS Lab Seminar - 8
Copyright 2009 by CEBT
Our approachOur approach
Assumption
Users continuously connected
– In order to notice real-time non-committed parallel modifications
However, this assumption can violate user privacy
As users may not agree to send draft changes of their work
A trade-off between privacy and the usefulness of awareness
To deal with this trade-off, a filtering mechanism is provided.
Ghost operation
Filter non-committed local operations before sending them to other users by masking some operation parameters
Filtered name, filtered type, and filtered value
IDS Lab Seminar - 9
Copyright 2009 by CEBT
Our approachOur approach
Send non-committed operations in real-time
Preserve user privacy by filtering the non-committed operations (ghost operations)
Example:
– op1= insert(User2,"file.txt",4,"Preventingblindmodifications")
Original operation
– g(op1) = insert(User2,"file.txt",4,30)
The content of the inserted line is masked.
– g(op1) = edit("file.txt",4)
The identity of the user is masked.
Trust metric may be used for automatic filtering
Integrate ghost operations as annotations within the document
IDS Lab Seminar - 10
Copyright 2009 by CEBT
Revisiting Motivating ExamplesRevisiting Motivating Examples
IDS Lab Seminar - 11
Generated Operations Privacy filter
Ghost operations
op1=delete(User1, Integer.java, 15-18)
No filter g(op1)=delete(User1, Integer.java, 15-18)
op2=update(User2, Integer.java, 16, "return false“)
Filter content g(op2)=update(User2, Integer.java, 16, -)
op3 : create IntegerTest.java
No ghost -
Copyright 2009 by CEBT
Interface User1Interface User1
op1 = delete(User1, Integer.java, 15-18)
g(op2) = update(User2, Integer.java, 16, -)
No ghost operation from User3
IDS Lab Seminar - 12
User1 will not validate the removal of method
isReal()
User1 will not validate the removal of method
isReal()
Copyright 2009 by CEBT
Interface User2Interface User2
op2 = update(User2, Integer.java, 16, "return false")
g(op1) = delete(User1, Integer.java, 15-18)
No ghost operation from User3
IDS Lab Seminar - 13
User2 is aware ofremoval of isReal() – canInitiate communication
User2 is aware ofremoval of isReal() – canInitiate communication
Copyright 2009 by CEBT
Interface User3Interface User3
op3 : createIntegerTest.java
g(op1) = delete(User1, Integer.java, 15-18)
g(op2) = update(User2, Integer.java, 16, -)
IDS Lab Seminar - 14
User3 can examine changes in Integer and
Postpone testing
User3 can examine changes in Integer and
Postpone testing
Copyright 2009 by CEBT
Conclusions and Future WorkConclusions and Future Work
Conclusions
Awareness approach for avoiding blind modifications (in text, wiki, source code documents)
Ghost operations
– Trade-off awareness
– Privacy
Future work
Develop a model for our proposed interaction mode (Operational Transformation Mechanism)
Provide users suitable interfaces for filtering
Implement a prototype for awareness in software engineering
Perform user studies
IDS Lab Seminar - 15