2 - Scott Lewis of the ECF Project

Daniel Spiewak: Hello, and welcome to the second episode of the EclipseZone Europa Podcast series. My name is Daniel Spiewak and I'm here with Scott Lewis of the ECF Project. So Scott, why don't you tell us a little bit about yourself?

Scott Lewis: Sure. I'm a software designer and entrepreneur. I have a PhD in experimental psychology, but I've been working in software development for approximately the last 20 years. I've been at Bell Laboratories and Intel Architecture Labs, previously doing R&D with distributed systems and real-time collaboration applications.


Now I'm primarily focused on working with software startups. I've been the founder of a startup myself. I work with startups doing open source-based applications. I started the ECF Project in the fall of 2005, and I've been the project lead since then.

Daniel: Well, what is ECF exactly?

Scott: Well ECF is an open framework for building messaging functions into Eclipse-based tools and applications. And so what do I mean by Eclipse-based tools and applications? They're Eclipse-based plug-ins which we want to support people building, for example, things like shared editors, real-time collaboration at the level of tooling, collaborative debugging is an area that has been of interest, or collaborative editing. And then also, file sharing at the level of workspaces and tools, that's one kind of Eclipse-based application area that we're interested in.


We're also interested in server-based applications. Eclipse on the server is now appropriately getting a lot of attention, and we'd like ECF to be used to support building some of those server-based applications. So for example, ECF has a bot framework that lets people introduce a chat box or other kinds of bot functionality into their team-build processes.


We also want to support RCP applications. So people who are building RCP applications that want to include real-time collaboration functions in those applications, integrated instant messaging and chat, using either public protocols like Yahoo or XMPP, or proprietary protocols, whichever they prefer.


Also, we would like to support eRCP applications, small RCP applications, like multi-user games. We've got some folks who are right now working on a multi-user Sudoku game that runs on the eRCP run-time. We have a number of APIs that are part of the framework, and that's a major part of ECF, basically, the APIs that we can provide.


So, for example, a presence IM in chat API, service discovery, bulletin boards for interacting with web-based bulletin boards, data sharing API, file transfer for either retrieving or sending files in real-time to peers. And then also, we're working quite a lot now with voice-over IP API for doing voice-over IP applications for supporting the building of voice-over IP applications.


We're working quite a lot with supporting remote OSGi services because OSGi is coming on strong, and we have a remote OSGi services API. And then we also have some supporting underlying APIs to support things like object replication in a distributed publish and subscribe group.


So that's a little bit about what ECF is from the application level and at the API level. We also have the notion of pluggable transports in ECF. These APIs that I mentioned before, like the presence API is not bound to a particular presence protocol, like for example, Yahoo, Skype or XMPP, which is also known as the Jabber protocol. But rather, the APIs are abstracted away from any particular protocol implementation.


And so we have the notion of various transports plugging in and implementing these APIs, and this allows us to support, for example, Jabber clients that use XMPP, Skype and Yahoo, and present the same kind of integrated user interface for the buddy list and/or the IM and chat. That notion of pluggable transports spreads throughout the entire architecture of ECF so that, for example, for file transfer, it's possible to use HTTP, FTP, bit torrent, or other file transfer protocols and use the same file transfer API at the application level.


An important part of ECF is that we're really protocol agnostic. We want to allow the creation of clients and server applications that are based on existing protocols or open source protocols or proprietary protocols, all three. We leave that decision up to the application developer, and we want to make it easier for applications to be developed.

Daniel: So how do you envision ECF being used?

Scott: Well we're hopeful that ECF will be used both for building applications and the applications that are built on ECF will also be used by users of Eclipse and these other applications. So we built, not only some APIs, but we have also built some simple example applications on top of ECF.


For example, a simple multi-protocol buddy list and instant messaging application. We hope that both developers who want to build these sorts of applications, or use ECF, and replace the parts of ECF that they don't want to use. People would use the applications that we've developed to just work together on distributed teams and do real time collaboration for words while using ECF and Eclipse.

Daniel: What about the VoIP support and ECF? How does that work?

Scott: We are working a lot now with voice over IP. We've defined an abstract, what we call a Call API. What that is, is it provides the basic application level API for doing call signaling and set up. We're now engaged in implementing different providers for that call API. One of the providers that we've just created is based on Skype. We can now control the Skype client and make calls via ECF based applications. Skype calls via ECF based applications.


We're also focusing quite a bit on integration of the Google Talk protocol, known as Jingle. There's a Google summer of code project specifically to create a Jingle provider for the ECF call API. We also have committers who are interested in introducing both SIP and Asterisk providers for the call APIs. What this would allow is that the single ECF based client to initiate or receive calls using SIP or the Asterisk open source PBX IAX protocol. We are also looking for additional community contributions so that we can support other providers more quickly. We're a relatively small team and so we want to support as many voice over IP protocols as we can in parallel, but we can only go so fast.

Daniel: Are we going to be able to see these improvements in Europa, or are we going to have to wait for later ECF release?

Scott: The Skype provider will likely be in Europa. The Jingle integration...there might be a working implementation of the Jingle protocol in that in the Europa time frame, but I would expect that to be a little later. If we can get further community contributions we could potentially introduce support for other providers more quickly, but those are the ones that I expect to be in place for Europa.

Daniel: OK, something to look forward to. So how does ECF relate to other collaboration tools like Corona? It seems like you provide a lot of the same things.

Scott: Well, actually, we're slightly lower level then Corona. That is, our APIs are really intended to support applications and frameworks like Corona. The Corona team is actually using ECF for doing the event distribution part of the Corona framework. In general, we're kind of lower level on the stack and are trying to support a broader set of applications.


Now, that being said, we've been working with the Corona team to introduce more collaboration features into Corona and provide the appropriate support in ECF for those applications. An example of this is the notion of having a real time shared editor where people are collaboratively working together within Eclipse, or some other Eclipse-based application, to do collaborative editing.


We had been working on introducing support for conflict detection and distributed state synchronization at the level of ECF and then at the level of Corona they can use those functions to build collaborative editors of different types for the distributed development team use case.

Daniel: What about IBM's Jazz project and ECF. Is there any interrelation there?

Scott: Well we're working on getting some integration there. I would very much like to have Jazz adopt using the ECF APIs and contribute to both defining and extending those APIs. As well as offer up some of the terrific both application level work and provider level work that Jazz is doing. So for example, they could contribute a same time provider to implement the ECF APIs, and I'd very much like to see that happen.


Now whether or not that will happen is I think partially up to the Jazz team and whether or not it fits the model for Jazz's commercialization.

Daniel: Along those lines, has there been any commercial interest in ECF?

Scott: Yes, absolutely. A number of Eclipse based tools companies would like to use ECF based messaging to introduce collaboration communication into their existing products or product suites. There are folks out there that would like to create, for example, shared editors providing their custom editor, but make it to be able to support real time collaboration by teams of users.


Then there are other companies that would like to introduce real time collaboration and messaging and team collaboration support into their product suites, but we'd like to use, and like to allow their customers to use, public open services like Skype, or Yahoo or even Google Talk to support the real time collaboration and have it integrated in with the clips. ECF can support that very easily since we support a number of both open and proprietary protocols.

Daniel: Is ECF sponsored or supported by any member companies?

Scott: No, not at this time. There are a couple of ECF committers who work for member companies, but generally their work on ECF is volunteered and not supported by their companies. We would like very much to change that and have been soliciting support either in the form of committers to work on the project or even just code contributions from existing member companies, but so far we haven't had any takers. Like I said we would very much like to change that.

Daniel: What do you see in store for ECF in the future?

Scott: Well, first of all, we want to have a very solid release for Europa so we are trying very hard to firm up our existing APIs, document things much more clearly and carefully, as well as work on the example applications and user interface so that people who sort of just try out ECF as users will have a good experience.


Then as we talked about where we are spending a lot of effort right now on voice over IP and supporting different multiple voice over IP providers like Skype and Google Talk and SIP and Asterisk. Plus we have plenty of enhancement requests for supporting additional transport like light same time, Skype is one of those as well.


We have requests for extending and enhancing the existing APIs so that as people begin to use the existing ECF APIs they inevitably find areas where they would like the APIs to support additional usage that we haven't anticipated so far. So we want to support people's usage of the APIs in ways we haven't anticipated.


We also want to do a lot more work on supporting Equinox or Eclipse based servers. Put in greater support for things like bought frameworks, as well as sort of messaging middle-ware kinds of usages of ECF. Particularly on server applications. We also are going to do quite a lot more work on integration with existing other projects.


For example, Corona is one of those. Another project that we've gotten a number of requests to integrate with, and there is a Google summer code project to do this, is work with the Mylar team so that the Mylar based tasks and task contexts can be exchanged, peer to peer via ECF.


We also are intent on working further on integration with the Equinox level work. One of the incubator projects that's planned for Equinox after the Europa release is a provisioning effort. We are already participating in a provisioning effort in supporting the ability to do download and updates via things like Bit Torrent protocols or file transfer protocols and, in fact, allow install and update to be preformed by whatever protocol people would like to plug in.


So those kinds of integrations are very high on our list of things to do. Further, we'd like to get some applications built on top of things like eRCP platforms and make those applications messaging and communication enabled for things like multiplayer games or like I said, multiplayer Sudoku. That's a good one. It's very popular.

Daniel: Yeah. [laughs]

Scott: We are very pleased to see that now working and we'd like to get it out and available so people can use it and feedback new needs.

Daniel: Sure, right. OK, any closing remarks?

Scott: Well, sure. Thanks, Daniel, for interviewing me and including the ECF project in the Europa podcasts. I'd also like to say that the ECF is a community based project so we depend quite a lot on community input.


I'd like to request the people listening out there that if you have some desires for ECF please speak up, and speak up in the news groups, or the mailing lists, or file bugs or enhancement requests and we will respond to them as much as we can. We depend upon the community quite a lot and we'd love it also if other people would consider contributing, if you have the interest and expertise. Please contribute as much as you can.

Daniel: Cool, cool. Thank you so much, Scott.

Scott: All right. Thank you, Dan.

Transcription by CastingWords