Introducing Collaboration to Single User Applications

1
Introducing Collaboration to Single User
Applications

• A Survey and Analysis of Recent Work
• by Brian Cornell
• For Collaborative Systems
• Fall 2006

2
Overview

• Much work has been done in researching
  collaboration
• Most applications are still single user
• These applications are already complex, adding
  collaboration would be difficult
• Some vendors don't see collaboration as a
  necessity
• We need to bring collaboration to these apps

3
Retrofitting

• Three layers of retrofitting
• Application Layer
• Modify the original application to add
  collaborative functionality
• Operating System Layer
• Intercept interactions between the application
  and operating system (e.g. screen sharing)
• Programming Environment Layer
• Exploit the API, runtime environment, or plugin
  system to insert collaboration

4
Motivating Example

• Example App Programming Editor
• Plain text files, syntax highlighting, etc
• Our ideal collaborative solutions would
• Allow multiple people to simultaneously use the
  app
• View and edit the text
• Allow people to chat about the text
• Provide awareness of who is editing what
• Provide status of other editors (away, idle, etc)
• Have minimal lag/latency
• Merge conflicts gracefully
• Not change the UI significantly

5
OS Level Screen Sharing

• Floor control introduces an input bottleneck
• Users not colocated with the app experience lag
• Especially when used over the Internet
• Aims for the being there feel only
• Supports any unmodified application
• Cross-platform capabilities
• For programming editor
• Get simultaneous view, same UI, maybe minimal
  awareness, asynchronous editing
• No chat, status, synchronous editing, merging, etc

6
App Level Reprogramming

• We could implement these features in the
  programming editor if we are given the source
• But we may not have the source code
• The editor may be very complex making
  modification difficult
• We must solve all of the problems ourselves and
  likely not in a reusable/common way

7
Environment Level Further Split

• At the programming environment level let us
  discuss three approaches
• Divide the level into three slices

8
Aspect Oriented Overview

• Use aspects to hook into related calls in the
  original application
• From the aspect code (advice), add collaborative
  information to the UI
• Example aspect pseudocode
• after(TextLine line) (target(line) call(
  TextLine.setText(..)))
• Add an icon to the line showing who last changed
  it based on information from external versioning
  software

9
Aspect Oriented Benefits

• Do not need to recompile application
• Can modify single objects or whole types of
  objects using complex rules
• Uses the original application data and objects
• Allows for access to application specific
  information
• In our programming editor we could get
• Rich awareness information
• Status
• Maybe IM capabilities
• UI Shouldn't change significantly

10
Aspect Oriented Downfalls

• Requires application to use a runtime environment
  that supports introspection and hooks
• The internal object structure could get
  prohibitively complex in many applications
• Can only provide collaboration assistance as a
  result of actions in the application
• In our editor we don't get
• Document synchronization of any kind, maybe not
  even chat

11
Plugin/extension Overview

• Use plugin or extension architecture to add
  components to single user applications
• New components support collaboration, or add
  collaboration to other parts of the application
• For example, perhaps our editor allows us to
  create additional panes in the window
• Content is controlled by a function loaded from a
  dynamic library
• No access to the rest of the application or
  document

12
Plugin/extension Benefits

• Don't need access to the source code
• Supports applications written in any language
• Application could potentially change, add more
  features, and plugin may still work or require
  only incremental update
• Application is designed to be extended using
  plugins/extensions, so proper support/hooks
  should already be provided and documented
• In our editor we could easily add awareness and
  status of collaborators and chat with a similar UI

13
Plugin/extension Downfalls

• Requires the base application to have plugin or
  extension support
• Many applications aren't designed for extension
• Plugins can only do what the application's
  extension architecture supports and allows
• Plugins can often only add components, not change
  the behavior of what is already there
• In our editor we can't access the document so
• No synchronization
• No contextual awareness (can't put an icon in the
  code)

14
Transparent Adaptation Overview

• Translate application actions through API into a
  sequence of events
• Correlate events to sequences of basic operations
  on a linear document
• Apply any consistency techniques to synchronize
  the operations/model
• Translate remote actions back into application
  actions using API

15
Example Consistency Technique Operational
Transform

• Transform future basic operations based on effect
  of current operation
• Example, string abc, operations Insert(1, 1,
  z) and Delete(3, 1, c)
• If insert is applied first and then delete
  naively, delete will delete the b rather than
  the c that it referenced
• When insert of length 1 is applied, all other
  operations are transformed by increasing their
  position by 1
• This is just an example, any technique could be
  applied to maintain consistency

16
Translating the API

• For this to work, the app must have some concept
  of a linear document
• API must have access
• Actions in the app are translated into Adapted
  Operations (AO)
• AOs are sent to remote sites and used by
  consistency technique
• Remote AOs are transformed, then applied to the
  local document using the API

17
Transparent Adaptation Benefits

• Single user application is completely unaware of
  collaboration
• Interface of application remains the same
• Allows simple collaboration no matter how complex
  the editor, as long as it can be linearized
• Does not require the application to use any
  specific language/infrastructure
• For our programming editor
• Synchronous Viewing and Editing
• Apply any desired merging system
• UI not changed at all

18
Transparent Adaptation Downfalls

• Only applicable to editor style applications
• Document or model must somehow linearize
• Application must provide a rich API
• The per-application adaptation could get quite
  complex
• No method for changing the application UI to add
  collaborative features
• For our programming editor
• No awareness, chat, status, etc

19
Comparison

• We get all of the features of our ideal editor
• Just not all from the same technique
• Perhaps if we combined all of the techniques
• Transparent Adaptation to synchronize the
  document
• Plugin to add chat and collaborators panes
• Aspect to insert contextual information from the
  other two into the actual editor UI
• All of the techniques maintain similar UI to the
  original application
• All also require per-app implementation

20
Scale

• Plugins and transparent adaptation more
  applicable to large applications while the
  aspects seem better suited for small applications
• Aspects require introspection and modification
  based on internal structure of app, could get too
  complex
• Plugins and transparent adaptation require a rich
  enough API or extension architecture, more likely
  to be available in a commercial large scale app

21
Conclusions

• None of these approaches is completely general or
  easy to adapt to new applications
• There is no perfect solution yet
• Perhaps we should explore the retrofitting layers
  in more detail, look for new ideas that may work
  better
• Many applications allow modification without
  access to source code
• If you don't put collaboration in your app, at
  least put in enough hooks for somebody else to
  add it for you

22
Questions?

• Send further questions/comments to
  brian_at_cs.unc.edu