Concretely, we are opening Eclipse for a whole new world of UI components called OpenSocial gadgets. You have probably seen gadgets in action already, on iGoogle homepages. You can find gadgets that, for example:
- display your Remember the Milk to-do list,
- show your Twitter feed (with updates every x minutes),
- provide your GMail inbox,
- show a calendar, or, most importantly:
- display the "cat photo of the day". :-)
In Eclipse, OpenSocial gadgets are hosted as views. This is what it looks like:
More information, including how you can contribute, is available on this wiki page. You can also download e4 M2 and play with it, or install the feature into a 3.5 or 3.6 build as described on the wiki page.
I think this is really exciting, and potentially an important part of the future of Eclipse. Here is why:
More information, including how you can contribute, is available on this wiki page. You can also download e4 M2 and play with it, or install the feature into a 3.5 or 3.6 build as described on the wiki page.
I think this is really exciting, and potentially an important part of the future of Eclipse. Here is why:
1. It makes it easy to add a new view (or editor) to Eclipse. Just write HTML, CSS, and JavaScript, and you don't even have to know that the gadget is going to be hosted in an Eclipse application. All the usual web arguments apply - zero install, all you need is a URL, proper sandboxing, etc.
2. It brings Eclipse and the "Open Web" closer together. Web UIs are becoming increasingly important, and who knows, we may at some point want to run a full-blown IDE in a browser. But until then, we need a way to take advantage of the web without losing everything that we already have - supporting the existing Eclipse plug-ins is important for the forseeable future. By bringing the web to Eclipse instead of bringing Eclipse to the web, we can get the best of both worlds, if we can ensure that gadgets can become first class citizens in a desktop Eclipse application. (See 4. for what I mean by "first class Eclipse citizen".)
3. It can make Eclipse more social. At this point, our implementation does not support the "social" part of OpenSocial gadgets, but if we added that support, it could serve as another integration point for plug-ins, similar to how the common resource model (projects/folders/files) is an important "common currency" for IDE plug-ins.
4. The OpenSocial specification could benefit, too. We have ten years of experience with Eclipse as a platform or, as I like to call it, as a client-configured mashup platform. Users can start with a minimal platform, add a whole bunch of plug-ins and get an application where individual pieces work together seamlessly. (OK, I admit, it's not seamless in some cases, things don't always work together well, and if you add an insane number of plug-ins, Eclipse is slow and bloated, but I hope you get the idea.) I honestly don't know which other platform has come as far as Eclipse has in terms of integration of heterogeneous components. If you look at examples of the kind of integration and seamlessness I list below, only the first two are currently addressed by the OpenSocial gadgets specification. Many of the other "integration points" that we offer in Eclipse would make sense for OpenSocial as well, if the goal is to support more than a bunch of independent gadgets that sit next to each other on a web page. Here is a partial list of what we call the Eclipse Application Services a.k.a. "the twenty things":
- Editing preferences in a consistent way.
- A common mechanism for localizing strings.
- Providing and listening to the current window-level selection.
- Being able to start long-running operations, with progress reporting and the ability to cancel.
- Indicating unsaved changes and prompting to save on close.
- Common undo and redo operations.
- Persisting UI state (e.g. column widths, sorting, etc).
- Error reporting.
- Common dialogs for common tasks.
- Contributing menu and toolbar items to a shared area (global menu or toolbar), or even to other views and editors in form of additional items in local menus or toolbars.
For the full list in draft form, and more details, check out the Eclipse Application Services wiki pages. Ignore the fact that most of these wiki pages describe API in Java - it wouldn't be hard to specify similar or equivalent API in JavaScript as well. We still have to find out how best to interact with the OpenSocial community, and if they would be interested in taking their spec to the next level as hinted at above.
On the Eclipse side, our plans for the coming weeks and months are roughly the following:
- Complete and solidify our implementation, which currently has high duct tape content.
- Investigate if we can reuse parts of Apache Shindig to make our job easier.
- Offer Eclipse Application Services as so-called "features" that gadgets can (optionally) depend on.
- Write example gadgets that show the kind of integration into Eclipse that we'd like to see.
Do you have an idea for a gadget that you would like to see in Eclipse? Would you like to join the fun and become an e4 committer to work on this with us? Let us know on the e4-dev mailing list if you would like to participate, or send me a direct email. Bugs and enhancement requests can be filed in Bugzilla.
Plain old comments on this blog are welcome too, of course. ;-)
1 - Similar to what Apache did with its httpd project and the 1.3.x and 2.x streams, we are planning two Eclipse SDK streams going forward - regular releases on the 3.x stream (3.6, 3.7, 3.8 ...) with a focus on stability, and a parallel 4.x stream with the innovative stuff.
Posts
9 comments:
Thanks Boris. The OpenSocial Gadgets are fascinating.
This is good stuff Boris. So how close are you to having these gadgets in the client?
One question I had was, is there a common viewpart for this and if so, how do you point it to different content (different gadgets).
@Bob:
By "having gadgets in the client", do you mean that they would be served by the running Eclipse instance itself? You can do that today - Eclipse already ships with an instance of Jetty for serving help content, it's just a matter of implementing the server side of a gadget based on that.
We do have a common ViewPart for this, it's a multi-instance view. The gadget URL is stored as the secondary view ID - this ensures that gadget views are persisted properly across sessions.
Hi Boris. A lot of this work seems to me rather closely related to what ECF has done...since we are already doing quite a lot with xmpp and other technologies/protocols related to open social.
Why not contribute it to ECF?...e.g. as IContainers/providers.
@Scott:
Not sure about the relationship to ECF - OpenSocial gadgets are a pure UI level integration technology, have you looked at the code yet? The wiki page has instructions..
@Bob:
If what you want to do is somewhat develop/debug your gadget locally, you can store the XML gadget description somewhere in your workspace. Then, instead of adding the gadget at URL "http://domain.com/gadget_def.xml", you will add instead "file:/c:/blah/workspace/gadget_def.xml".
The gadget will be opened in the exact same manner, and the bonus is that if you change and save the XML file in your workspace, the view will refresh itself immediately.
Hi Boris. I have looked at the OpenSocial APIs briefly...I understand that they are primarily intended for browser-based operation. However, I think the OpenSocial client libraries could probably be made available in java via ECF providers (for client communication with out-of-process servers), and there probably could also be some usage/extension of the newly-refactored ECF REST API. There may be other possible leverage points perhaps on OSGi servers (where a lot of work is focused these days for ECF)...e.g. the ECF xmpp provider, or the forthcoming ECF google wave support, or perhaps the work done last summer on the Google Services Provider for ECF Google SOC project.
It would be interesting to see how the gadget feature support will progress.
How is OpenSocial implemented at the moment within Eclipse E4?
I believe it would save you a lot of time if you go with Apache Shindig and then incrementally implement the service interfaces (PeopleService, ActivityService, AppDataService, MessageService) and their methods as you see fit. One thing is sure, Shindig project is consistently maturing.
Along the way, with an increased number of features being supported many interesting gadget can be envisioned, e.g. XMPP/GTalk chat and using sharedstate feature (used by GTalk gadget and realtime extension of this feature) to implement remote pair programming (something Eclipse project Cola tried to do).
Cheers!
Shonzilla
I don't think it's a stretch to say that OpenSocial could allow developers using Atlassian dev tools to perform almost every day-to-day task without leaving the IDE. Between the coding tools available in Eclipse, Mylyn for task management, and OpenSocial for gadgets, I think this could become a reality!
Post a Comment