null
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
Java, the OLPC, and community responsibility
The "One Laptop Per Child" project has a great device ready to ship, but there's no Java on there. Let's think about working together to put Java on OLPC!Eclipse Project Series: The ECF Project
Real-time communication via the internet has revolutionized the way we work and play together. It has also made application development a lot more complex; as new protocols become available, you have you have to worry about which ones to code and support. The Eclipse Communication Framework (ECF) lets application developers create these communication-aware programs more quickly, while hiding the details behind an extensible plug-in based API. The team leader of the ECF project, Dr. Scott Lewis, recently agreed to talk to EclipseZone about the project's vision for the future of connected application development.
[Ed] Could you briefly explain what ECF is?
[Scott] ECF is a framework for building communications and messaging into Eclipse and/or Eclipse RCP applications. The framework is based upon a simple but extensible abstraction we refer to as a 'lightweight communications container'. In parallel with the developer community, we are building plug-ins and applications that use the framework; for example Instant Messaging/chat clients, multi-user editors, peer-to-peer and client-server file transfer, and shared web-browsing. We're looking forward to supporting VOIP applications soon. Our expectation is that a variety of communications applications will drive the 'hardening' of the framework itself.
What do you mean by 'lightweight communications container'?
The ECF API has a core type called org.eclipse.ecf.core.IContainer. IContainer instances provide a common context for communication between two or more processes. ECF also has an extension point called org.eclipse.ecf.containerFactory that plug-in developers can use to register implementations of the IContainer interface. By using multiple IContainer instances, many protocols may be supported in a single application.
So does that mean you support MSN, Yahoo, and AOL protocols? Could I use it to write a multi-protocol chat client like Gaim or Trillian?
ECF's whole purpose in life is to be a cross-protocol API, so I believe it would be an excellent basis of a multi-protocol client like Gaim or Trillian. In fact, it's my hope that people will write clients that not only are multi-protocol chat clients, but also clients that have integrated file sharing, instant messaging, VOIP, conferencing, shared model editors, app-specific communications functionality, and so forth.
Is VOIP standardized enough that you could be compatible with other systems like Skype?
Unfortunately, it doesn't seem to me that standards are at that point yet. ECF can in theory support both Skype and other VOIP protocols simultaneously, but we need to sequence our efforts given that we are a small team. Lately we've been focusing on SIP for VOIP. We would love to immediately support Skype, however, so if any of your readers are interested in working with us on a Skype ECF provider, please let us know.
Tell us a bit about how ECF is developed. I understand it's not quite the same as most Eclipse projects.
ECF is currently an all volunteer project. All the ECF committers are experienced software professionals who have a personal desire to create a useful, extensible, interoperability framework for their own use and use by other developers. All of us work on this nights and weekends, with no payment. Each of the committers has different reasons for working on ECF, but I think we would all say the merger of Eclipse with support for messaging and communications makes for some very interesting and fun technology work.
Being all volunteer has advantages and disadvantages, as you might expect. One significant advantage is that we have no corporate agenda, and can look to provide a communications framework and APIs that deliver cross-protocol and cross-vendor interoperability - free of any kind of protocol bias or vendor 'lock-in'. This freedom is very useful for being able to serve the interests of the development community.
The largest disadvantage is that we have to struggle to move rapidly to implement new providers, create new applications, write documentation, and provide support. The framework and APIs are reasonably mature technically, but it needs widespread usage and feedback to be completed.
We would like to acknowledge all the help we've received from the Eclipse Foundation leadership (especially Mike Milinkovich and Bjorn Freeman-Benson), Intel, and the Oregon State University Open Source lab. A sincere thanks to all the folks that have helped us so far... and those that step up to help us moving forward.
What drives someone to put in so much effort on a volunteer project?
Many of us want interoperability between communications systems to be the rule, rather than the exception in application development. For example, if you're building an application for doing forms input and workflow, and would like to embed instant messaging and presence functionality directly into your application, the lack of interoperability between instant messaging systems creates tremendous problems for you and your users. It would be nice to expect that communications is needed in an application, enable application developers to write to a 'presence' API, and be able to get the user presence functionality published by that API, independent of the service or network vendor's specific protocol. I think this would drive an expectation that communications between various implementations of a given functionality (e.g. presence/IM) would work consistently across various services, and deliver interoperability between applications.
Have you gotten any interest from people who might want to make full fledged applications based on this technology?
Yes, in fact some folks responsible for creating a full-fledged application called WiredReach have recently joined the ECF committer team to work further on the ECF framework. Our hope is that we will soon have additional interest from people that would like to build their applications using ECF, as we think it would be useful for building a number of very interesting applications, from games, to workflow, to conferencing, to multi-user authoring.
What does ECF make possible that wasn't possible (or was too hard) before?
Probably the most important thing is the easy creation of multi-protocol clients. More and more, application developers have a need to create integrated user interfaces that speak a number of different messaging protocols. One example of this is instant messaging applications like Gaim. Users naturally like the interoperability that comes from a single application that speaks multiple IM protocols.
ECF and Eclipse RCP take the notion of multi-protocol clients a step further. Eclipse is a universal tools platform, right? Well, ECF allows the easy creation of tools that integrate both at the user interface level (using Eclipse/Eclipse RCP), AND at the protocol/communications level (using ECF APIs along with provider extensions). Interoperability between instant messaging protocols is supported by ECF, but ECF also is intended to support interoperability between other kinds of real-time and non-realtime communications, for example file sharing, remote control, data conferencing, VOIP, shared editors, and so forth. Imagine an application that could use BitTorrent, ftp, IM, LiveMeeting services... all integrated at the user interface to present the appropriate features at the appropriate time. Now imagine not having to write all of the custom communications code for talking to all those services, but rather using open provider implementations exposed via ECF APIs.
Sun recently demonstrated a shared-development component for NetBeans. Do you see Eclipse (with ECF) going this way too?
I expect we'll see ECF provide a UI and service for Eclipse/Eclipse Foundation teams/projects this fall (2005). By that time we plan to have basic IM, chat, and collaboration functionality in place, with sufficient server and bandwidth resources that we'll be able to offer ECF-based IM, chat, and basic real-time collaboration to all interested Eclipse project teams.
Actually wasn't that what Koi was supposed to be? Why do you think that didn't work out?
I think that Koi had some technical weaknesses, for example using XML-RPC for the wire protocol. This bound applications to a particular client-server communications architecture. More importantly perhaps, because of its timing Koi didn't have access to the Eclipse 3/OSGI component model. This model is used for something very central to ECF: the ability to add new providers via ECF extensions. For example, we're working on completing a JMS implementation as an ECF provider.
Has anybody done a game with ECF? What kind of game could you do?
Not yet that I know of. I hope someone does one soon, or otherwise I'm going to have do the first one. ECF would be well suited to creating lots of multiplayer games, but I think it would be particularly good for building games that have a strong end-user creation aspect to them. For example, a multiplayer role playing game, where everyone creates multi-media artifacts that they then share or trade them among one another could really shine using ECF alongside other Eclipse technologies like RCP, EMF, GEF and others. And given the extensibility that comes with Eclipse's plug-in architecture and ECF, such a game would be able to change and adapt at runtime without the game developers having to start from scratch building each new feature. That level of end-user extensibility could make for a very fun and interesting multiplayer game.
You recently came out with a new version, 0.4.0. What new or improved features does it have?
The main new user features in 0.4.0 are support for Jabber/XMPP Multi-User Chat, Google Talk IM, and multiple Jabber/XMPP accounts in a single buddy list. There are also a number of bug fixes and improvements in the collaboration example applications, which already have group chat, URL sharing and file sharing, and a simple demonstration collaborative graphical model editor based upon GEF and EMF. These are meant primarily to be examples for use of the ECF APIs rather than full-blown applications, but they are useful as team communication enhancements to the Eclipse IDE in and of themselves, and they are licensed under the EPL so they are completely open and available for other people to use and build upon. I use the ECF IM client and chat client daily, for example, to keep in close touch with the rest of the ECF team. The API changes in 0.4.0 simplified the creation of both client applications and ECF providers. For example, the ECF namespace extension point, which allows providers to define and use their own types of identity and authorization, was greatly simplified for 0.4.0.
What are the plans for future releases? When will there be a 1.0?
On the application side, we are planning feature enhancements to the existing example applications: IM, real-time data conferencing, and shared model editing. We are planning significant new applications such as a soft phone for VOIP, support for dynamic service discovery, and integration with web authoring and distribution systems like blogs, wikis, and RSS/Atom. Finally, we're actively supporting and collaborating with other Eclipse projects that need communications and messaging services such as the Higgins Trust Framework project, and the Device Software Development Platform project.
It's pretty clear to me that ECF as a framework can/should support the creation of at least two large classes of applications: 'conferencing' applications, where people communicate via a variety of media in real time (e.g. voice/VOIP, IM/text chat, file sharing, url sharing, etc), and 'shared editor' applications, that allow teams to collaboratively construct structured artifacts such as web pages, other documents, simulations, and models of different types (e.g. UML models). The ECF team will deliver to the Eclipse users (and/or the Eclipse RCP users) functioning instances of both classes. We hope that these can be useful apps by themselves, but also that other plug-in developers will build upon them (or build their own using the ECF-provided framework), and integrate them into their own Eclipse plug-ins and/or Eclipse RCP applications.
Our initial plan had our 1.0 release scheduled for Q1 2006. It may come sooner than that.
What else do you do besides ECF?
I personally have a day job as a software architect for a small software company named Cayuse, Inc.. They provide software to enable electronic submission of grant proposals to NIH, NSF, and other granting agencies. Between ECF, my day job, and my family that pretty much occupies most of my days...and nights :).
Anything else you want to share with us?
One last comment. For those of you that are interested in ECF-provided features or APIs, please consider getting involved to deliver support for your favorite protocol provider or application. Make your wishes known in the Eclipse Communication Framework user forum (hosted here at EclipseZone or via a newsgroup at eclipse.org), or the ECF developers mailing list. Contact the ECF team and consider providing code contributions, become a committer or contributor, or help out with tutorials or other documentation. Thanks!
Bios
Dr. Scott Lewis is the project lead for the Eclipse Communications Framework (ECF). He's been working on software for communications and distributed applications for too long. He is passionate about making Eclipse/Eclipse RCP an open platform for integrated and interoperable communications applications. Scott also serves as an elected committer representative to the Eclipse Foundation Board of Directors. In this role he tries to represent the needs and interests of the Eclipse committers on the Foundation Board. You can contact Scott at slewis at composent.com, or via IM at scottslewis at gmail.com or scottblewis at yahoo.com.
For more information
Project Home Page
Overview and API
docs
Downloads
Mailing List and
Newsgroup
Contact information
Yahoo: scottblewis, AOL: scottslewis,
ECF Jabber: slewis, server ecf1.osuosl.org
Google Talk: scottslewis, server gmail.com
