1. Université catholique de Louvain (UCL) Belgian Laboratory of Computer-Human Interaction (BCHI) Place des Doyens, 1 B-1348 Louvain-la-Neuve (Belgium) Presented by Attach me, Detach me, Assemble me like You Work Donatien Grolaux grolaux@isys.ucl.ac.be Researcher at BCHI lab, http://www.isys.ucl.ac.be/bchi

2. Outline Demonstration Migration principles: DEMIPLAT Other goals Architecture overview Conclusion

3. Demonstration

4. Demonstration using two computers

5. Example using a Pocket PC

6. UI Migration: DEMIPLAT Detach

7. UI Migration: DEMIPLAT Detach - Migrate

8. UI Migration: DEMIPLAT Detach - Migrate - Plastify

9. UI Migration: DEMIPLAT Detach - Migrate - Plastify - Attach

10. This is not a floating toolbar Process

11. Computer B Process This is migration ! Process Computer A

12. Other goals Migration mechanism at the application level –Not at the OS/Windowing system level –Full control of what is migratable and what is not –Full control on how the user migrates stuff –Cross-platform (VM on Windows, Linux, OSX, Solaris, …) Development cost as minimal as possible –No perceivable difference between stationary and migratable UIs from the application’s perspective Infrastructure cost as minimal as possible –The application creating a migratable UI acts as a server for this particular UI. –The application attaching a migratable UI to its own acts as a client for this particilar UI. –No extra infrastructure or configuration required.

13. Display Site Architecture overview Transparent proxy mechanisms –Proxies are empty shells relaying messages to actual widgets –Proxies react as the actual widget from the application’s perspective Application Site Communication Manager Functional CoreWidget 1 Proxy Widget 2 Proxy Widget … Proxy Widget N Proxy Widget 1 Widget 2 Widget … Widget N User Interface (using TCP)

14. Display Site Architecture overview Transparent proxy mechanisms –Proxies relay event bindings from the functional core –Widgets trigger these events inside the CM at the display site –The CM relays and triggers the event at the application site –Proxies store all their event bindings Application Site Communication Manager Functional CoreWidget 1 Proxy Widget 2 Proxy Widget … Proxy Widget N Proxy Widget 1 Widget 2 Widget … Widget N User Interface (using TCP) Event Listener Event Triggerer

15. Display Site Architecture overview Transparent proxy mechanisms –Proxies act as storage when migrating away from a site –All visual aspects of all the widgets are stored by their proxies Application Site Communication Manager Functional Core Widget Proxy Event bindings Attribute values Widget User Interface (using TCP) Attr1 Attr2 AttrN

16. Display Site Architecture overview Transparent proxy mechanisms –When arriving at a site, all widgets are created –Their visual aspects are restored –Their event bindings are restored Application Site Communication Manager Functional Core Widget Proxy Event bindings Attribute values Widget User Interface (using TCP) Attr1 Attr2 AttrN

17. Application Programming Interface A window is either stationary or migratable –Decided at creation time, and once for all –Migratable windows are migrated with all their contents along –One can use composition to split a stationary window into a combination of several stationary/migratable sub-windows A migratable window can return a universal reference –A text string (encoding the IP address, a socket number, and an internal memory address) –Can be passed along using any medium New widget: receiver –Has a method to import a migratable window from its universal reference

18. Composition principle 3 independent parts that we want to migrate How is it possible to turn an already existing stationary application into a (partly/fully) migratable one ?

19. Composition principle They are turned into 3 different migratable windows

20. Composition principle The space these migratable windows used to occupy are replaced by receiver widgets receiver

21. Composition principle At the application start- up, the migratable windows are placed into their corresponding receiver widget receiver

22. Composition principle The application looks exactly the same as when we started, but now the three green parts are migratable.

23. QTkDraw example ~5k lines of code for the original stationary version 50 lines of code to enable the toolbars migration The receiving palette application is also around 50 lines of code Nothing in the functional core of the application had to change !

24. A word on Oz, Mozart, and QTk Research platform: www.mozart-oz.org Support for OO programming style –OO binding for Tcl/Tk as the backend toolkit Support for high level data structures –Oz record is expressively equivalent to XML –The QTk binding uses a mixed declarative/imperative approach for building and running the UI QTk is part of the standard Mozart/Oz distribution Support for functional programming style –Well suited for manipulating records –UI can be (partly) calculated dynamically –Well suited for adaptive UIs Support for concurrency and distributed programming –Reduces greatly the cost of developing the distributed communication manager

25. Conclusion and future work This version is a proof of concept prototype, hacked over an already existing binding for the Tcl/Tk toolkit –Works well enough for demo applications, but not for real applications –Proof of concept this is a nice approach for minimizing development cost when adding migration support to an (already existing) application Currently working on a newer version –Will support different rendering engines (Tcl/Tk, GTk, Web Browser, …) –Proxies are no more empty shells, they can (at least partly) function when not connected to an actual widget –Support for P2P networks –Support for more adaptation mechanisms –Robust implementation