User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618
I thought about the kinds of applications that I believe would be
enabled by this project, and I think they roughly fall into two
categories, one consisting of existing tools that are now enabled for
"remoting", and of course completely new tools.
For instance, collaborative debugging, web content creation, model
sharing, etc., would fall into the first category. Basically, one can
think of this as enabling other users to manipulate your own workspace
remotely, in real time, through their own user interfaces. It seems to
me that this rather general capability could be applied to plug-ins
Platform-wide. Some of the major issues to address here are security
(authentication/authorization), code compatibility, and network latency.
The potential benefits, however, are significant; this capability would
enable a whole new kind of tranining, troubleshooting, pair programming,
etc. Personally, I spend significant time on a daily basis documenting
solutions to problems involving WSAD workspace setup, such as
customizing server configurations, configuring external builders, etc.
This often involves an e-mail describing the click-by-click steps that a
developer must perform, and often ends in one-on-one troubleshooting of
exceptional cases. This is sometimes difficult, as some developers are
on the other side of the planet (this is when VNC comes handy).
A whole new class of tools that could be built using the proposed
framework includes things like instant messaging and group conferencing
over various channels. At S1, we found instant messaging to be
indispensable, again mostly for real-time troubleshooting. This feature
would greatly compliment the ability to share existing tools.
The underlying theme in both categories of tools is sharing of state
with remote Platform instances; existing tools share their intrinsic
state (and do not necessarily need to know about it), and tools like the
instant messaging client create state explicitly for sharing (i.e., you
don't want to chat with yourself; the messages you create are really for
others to see).
At some level, real-time team collaboration seems like an extension of
the asynchronous team support already in Eclipse, which enables sharing
of resources via version control systems as well as protocols such as
WebDAV and FTP. However, real-time collaboration would extend beyond the
workspace (i.e., resources) and would include a plug-in's "session"
state in general.
I believe it would benefit this project to produce a reference
application that would be of immediate utility to the developer
community. A good candidate would be the instant messaging client with
file and application sharing, complemented with collaborative source
code editing and/or debugging (possibly over the same conversation). A
large contributor to success of a new API is its acceptance by the
developer community, and what better way to facilitate that than to
provide something useful at the same time.
This project is off to a good start given that much of this
functionality is baselined in Scott's previous work. I think we can
already demonstrate some of this and rapidly make progress by expanding
on Scott's work. Hopefully we can get started as soon as this project is
approved.