1. 1 Introducing Collaboration to Single User Applications A Survey and Analysis of Recent Work by Brian Cornell For Collaborative Systems Fall 2006

2. 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. 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. 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. 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. 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. 7 Environment Level: Further Split  At the programming environment level let us discuss three approaches  Divide the level into three slices

8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22 Questions?  Send further questions/comments to brian@cs.unc.edu