So I have been thinking about how to incorporate Terracotta into the applications that I work on at my job for a while and so far we have come up with some good ideas as to how to leverage the Distributed Shared Objects ( or DSOs ), but it occurred to me today that there is something really, really cool that could be done with DSOs and Eclipse in a team/pair programming situation.
Maybe you see where I am going with this, maybe not. But here it is. Create an Eclipse plug-in or extension that bootstraps the Eclipse editor classes so that we can make them shared objects in the Terracotta shared heap space.
I'll let that sink in for a second...
Ok, so now all you XP aficionados can take your pair-programming to a new level without the need for fancy pair-programming stations. Have the Eclipse editor classes shared in the heap, so when developer A starts writing code on workstation X, developer B can see the changes in his Eclipse on workstation Y. To start this up, developer A would just need to have the Terracotta server running on workstation X and the developer B would need to point his Eclipse at the Terracotta server running on workstation A. Then kablammo! A shared editing environment for free.
A sample of how this works can be seen with the samples that come with Terracotta, specifically the "Shared Graphics Editor" that they ship with the download. In playing around with the graphics editor you can see that as changes are made in instance 1 of the editor they appear in instance 2 which can be running on a separate machine, while the Terracotta server is running on the same box as instance 1.
I think I am going to venture into the world of Eclipse plug-ins to see if I can get a working example of this. I want to know what others think of this. Leave a comment and let me know if you would be interested in seeing something like this.
Subscribe to:
Post Comments (Atom)
3 comments:
Kewl idea. One of our guys here at Terracotta built it. He took only 1 day to prototype and concluded that it is quite hard to cluster Eclipse...
More specifically, he found that properly sharing (and locking) the rich editor context was far more complex than it appears at a first glance. It would be interesting to compare to what the Eclipse Communication Framework guys did to implement their shared editing features as there is probably some overlap in goals, if not in actual implementation.
@Alex yeah totally. at looking at their project page it appears that they are sending messages between the clients over a variety of protocols. It would be interesting to talk to them to see what their endpoints are and to see how instead of sending messages they could some how update the objects in the shared heap. Convert the objects that listen for the messages to just live in the shared heap and have them listen for changes there.
Post a Comment