The Screen Sharing service wraps vnc or other screen scraping/remote desktop clients on a host and provides the ability to forward one's screen or watch another's using the wrapped functionality. To incorporate an implementation other than vnc, the service requires significant redesign.
Idea of how to redesign screen sharing service to cope with multiple implementations and being able to dynamically select a preferred one to use:
Entities
ScreenConnection (Entity)
ComputerEntity
bundles:
properties file livespace.screen_sharing.peer.properties:
screen_sharing.min_port = 53053 screen_sharing.max_port = 54053 screen_sharing.startup_timeout = 5000 screen_sharing.prefs.allow_watch = allow screen_sharing.prefs.allow_control = ask screen_sharing.prefs.allow_forward = allow # AUTHENTICATION UNSUPPORTED #screen_sharing.vnc.authentication = off #screen_sharing.vnc.authentication.simple_password = Livespaces42! driver.vnc = livespace.services.screen_sharing.vnc driver.vt = livespace.services.screen_sharing.vt preferred_order=vt,vnc
Impl bundles will have a screensharing implementation (e.g. vnc or vt) and classes to drive those implementations with an Activator to set stuff up. The Activators will publish the same bundle name for different platforms, bundle only the right bundle will be run on each platform, nicely avoiding any platform-specific bundle-loading issues. The Activator will do stuff like extract bundle files (e.g. zip file of vnc exes) and blow away registry entries and stuff, as well as instantiate and register factories for classes implementing IScreenSharingServer and IScreenSharingClient, which can then be found by the screen sharing peer Activator using the same bundle finding that's used by the Dashboard for finding panels to host.
UI Issues
The screen sharing widget would need to watch for which source computers and target computers are compatible (filtering down the source or target list when a computer is selected in the other list - but only if this can be explained to the user). If both protocols are available, somehow we need to decide which to use? Don't use VT across the WAN - this could be left to federation not federating support for that. We could do that. In fact, you could start to expose what other features are supported - e.g. the mac clients don't scale, so the scale Spinner should be removed when a mac client is selected. Grey stuff out where you can.