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


Collaborative EditingCollaborative Editing

IDS Lab Seminar - 3

Blind modification

When user modify a document without being aware of concurrent changes


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


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


Motivating ExampleMotivating Example

Actions User1 Actions User2 Actions User3

Removes method isReal

updates method isReal

creates test class IntegerTest

IDS Lab Seminar - 6


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


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


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


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


Revisiting Motivating ExamplesRevisiting Motivating Examples


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 -


Interface User1Interface User1

op1 = delete(User1, Integer.java, 15-18)

g(op2) = update(User2, Integer.java, 16, -)

No ghost operation from User3


User1 will not validate the removal of method

isReal()

User1 will not validate the removal of method

isReal()



op2 = update(User2, Integer.java, 16, "return false")

g(op1) = delete(User1, Integer.java, 15-18)

No ghost operation from User3


User2 is aware ofremoval of isReal() – canInitiate communication

User2 is aware ofremoval of isReal() – canInitiate communication



op3 : createIntegerTest.java

g(op1) = delete(User1, Integer.java, 15-18)

g(op2) = update(User2, Integer.java, 16, -)


User3 can examine changes in Integer and

Postpone testing

User3 can examine changes in Integer and

Postpone testing


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



DiscussionDiscussion

Pros

The idea focus on not managing conflict after the task is done, but managing it during the task

Consider privacy

Cons

Assume many users modify same document or page,

– Can this approach be effective?


A Collaborative Writing Mode for Avoiding Blind Modifications Center for E-Business Technology Seoul...

Documents

Transcript of A Collaborative Writing Mode for Avoiding Blind Modifications Center for E-Business Technology Seoul...