4 - Doug Gaff of the DSDP Project

Daniel Spiewak: Hello, and welcome to the fourth episode of the EclipseZone Europa Podcast series. My name is Daniel Spiewak, and I'm here with Doug Gaff of the DSDP Project.

So, why don't you tell us a little bit about yourself?

Doug Gaff: Sure. My name is Doug Gaff. Obviously, I'm a software engineering manager at Wind River Systems.

My primary role of late has been to staff our Eclipse open-source contributions in the various projects that Wind River participates in. Also, I'm at least partially responsible for the commercial adoption of those technologies back into our commercial Wind River Workbench product.

Daniel: OK. Well, what is DSDP?

Doug: DSDP stands for Device Software Development Platform. It was founded in March of 2005 by Wind River, really as a way to address the limitations in Eclipse around the embedded and device software space.

We started with a couple of projects that Wind River had a specific interest in and a specific need commercially, but the project grew fairly rapidly beyond what we originally envisioned. We ended up with six projects currently in DSDP, and it covers different areas of the embedded and mobile space.

As of right about now, we've got half a million lines of software code spread out among the projects in DSDP. We've got about 40 committers from 11 or 12 companies. Some people are in transition, so it's soon to be 12 companies. And then we've got participation in various forms from probably another eight companies in the various projects.

So, it's grown fairly quickly since we created it. We added the MTJ and NAB projects in January of '06, and ERCP came in July, and then TML came in August of last year. So last year was kind of a growth year in terms of project creation.

I've got a couple of other project proposals in the works that companies have brought to the table and they're interested in sponsoring, so we'll see how that plays out. But I would expect this year we may have one or two more projects that go through the creation process.

Daniel: Wow. Can you tell us a little bit about the DSDP sub-projects?

Doug: Sure. These projects could really be podcasts of their own. The thing about DSDP that's a little bit different than some of the other projects in Eclipse is that we're really a collection of independent technology projects. There are certainly technical connections between some of the projects, but unlike the Platform project or the BIRT Project where the sub-projects are kind of components of the bigger whole, DSDP is really more like the tools project or the technology project, where the sub-projects are full technology stacks in and of themselves.

The reason they're in DSDP is because they have some relationship to embedded development or mobile development. Again, we sort of created DSDP to fill a niche that was missing in Eclipse, and because of that we're getting this diversity of technology projects coming in.

That being said, you can kind of divide the projects up into three different categories. What I call traditional embedded -- people that come out of the computer engineering programs in universities sort of have a concept of embedded in their heads. And the device debugging and target management projects sort of fall into this traditional embedded category. I think we'll probably get to the projects a little later on in this podcast, so I won't go into too much detail right now.

The second projects are mobile Java. And this is for Java specifically on hand-held devices and Java that runs in other embedded projects.

And then the third category is really mobile C++. So, mobile Java is MTJ and ERCP projects, and mobile C++ is Native Application Builder (NAB) and Tools for Mobile Linux (TML).

Daniel: OK. Well, I have a lot of SWT applications that I've written over the years, and they obviously run on the desktop, on Linux or Mac or Windows. Does ERCP allow me to run those SWT applications on just any mobile device?

Doug: The answer to that is really a qualified "yes." The ERCP project is specifically focused on porting the standard rich client platform in Eclipse to mobile devices. So the same packages you find in RCP -- like OSGI and SWT, jPhase, Workbench, Update -- all of those have sort of e-versions (eWorkbench, eUpdate) that have been ported to run on mobile devices.

The real effort in ERCP is sort of the runtime layer, connecting the rich client platform to the specific mobile device. Predominantly, that work is done in the SWT package, and SWT has to be extended in some cases to work on specific devices.

That caveat is, as with standard SWT, it has to be ported to the specific platform that you're interested in, so ERCP has ported to a handful of platforms that are of commercial interest to the companies participating in ERCP. So, IBM and Nokia are the two primary companies in ERCP, with IBM leading.

They've ported it to Windows Mobile 2003 and 2005 with eProfessional. And then Nokia Series 80 and Win32. They're also coming up with Series 60 here shortly.

So, if you got a device running one of those supported platforms, and in general, it could really be almost any device running one of those supported platforms, you can typically run ERCP with the caveats that your application is going to have to adjust itself for the screen real estate and adjust itself for the type of input mechanisms you have, and that sort of thing.

But in general, the concept is to capture the desktop refugee and put them on a mobile device.

Daniel: Well, that's pretty cool.

Doug: Yeah, it's a good project. I guess one other thing I would mention about that is that Sprint, the service provider, is looking at making ERCP a standard on their next mobile platform. This was announced, I believe, at EclipseCon earlier this year. But they're looking at declaring a version of ERCP as the standard, and that will be deployed on many, many mobile devices now in the cell phone space.

So, it's very, very exciting for the ERCP project.

Daniel: Wow. I hadn't heard of that. So, big news. OK. Well, to sort of turn a corner away from ERCP, as interesting as it is, what part of mobile Java development does MTJ cover?

Doug: That's a good question. The two projects cover sort of different parts of mobile Java. ERCP is really focused on the beefier Java devices, Java devices that run the CLDC foundation profile. It's JME still, Java Micro Edition, but it's sort of a beefier version of JME with user-interface capabilities and a lot more packages than you would find on, say, a scaled-back version, which is the Midp profile, the CLDC and Midp profile.

MTJ is more focused on the rest of the mobile development life cycle, the Java development life cycle. So, they've got device and emulator frameworks for connecting your development environment up to a specific device, and then deployment capabilities for deploying images to the device. And build processes, remote mobile debugging, because obviously at some point, you've got to move the emulator framework to the actual device itself.

They also have the standard stuff: application creation wizards and localization, optimization, security. They're working on some UI design tools now. MTJ sort of originally founded itself to focus on the smaller mobile devices that have the CLDC configuration of JME, so they have build capabilities to build the beefier devices, but they're really focused more on CLDC right now.

And ERCP covers the windowing end and bringing the Eclipse user interface experience and capability set to the mobile device. So, that's kind of the difference between the two. There's a natural synergy, I think, that as the project evolves, they'll start having more tendrils into each other.

Daniel: All right. Well, what about NAB? Is it sort of an SWT for C++?

Doug: Conceptually, it's an SWT fro C++, in that it's a windowing library and a widget set written in C++ to run on mobile devices. So I guess it's more eSWT for C++. I think what's interesting about the NAB project is that the project came from an existing open-source community called Wide Studio that's kind of a Japanese-centric development community focused on building these mobile applications in C++.

So, there are actually a lot of deployed devices running the runtime libraries that NAB uses for visual development, and that's been true for quite a while now. NAB came to Eclipse last year and said, "We've got this great technology, but we need to take the stand-alone development environment that we built to support this and we need to port it to Eclipse because there's so much in Eclipse that you can use out of the box." The CDP Project and visual editing and all the standard stuff that commercial companies pick up when they decide to adopt Eclipse for their technology.

And NAB wanted to do the same thing with their open source project, so they wanted to leverage CDT and they wanted the forms editor for building the interfaces right inside of Eclipse and the Eclipse editor framework. And then they wanted to have the whole edit/compile/debug cycle right there inside of Eclipse.

So, Fujitsu was the primary sponsor of NAB. The committers on NAB were from Fujitsu. And there's a connection between the NAB project and the still-existing WideStudio.org open source community.

And the NAB project takes care of the Eclipse side, the tooling side, and Wide Studio takes care of the runtime side. So, taking those windowing libraries and porting them to specific real-time operating systems and host platforms. So, predominately, you'll see the typical Japanese real-time operating systems like ITRON and such. You'll see all the host operating systems for prototyping NAB user interfaces.

But they have the same sort of requirement that eSWT has, in that to move the library to a new mobile device you've got to support the operating system in question. What NAB is trying to do right now as a project is expand the number of operating systems that are supported, both commercially, so there could be commercial versions of the runtimes, and then open source versions for people who want to contribute the runtimes in open source.

Daniel: Is there a plan at all in the works to have sort of like a macro-NAB? So, like SWT is to eSWT, could we have an NAB that would run on the desktop? A full SWT for C++?

Doug: Yeah. Technically that exists already with NAB, because they've ported the NWT, the multi-platform widget toolkit to all of the standard host operating systems now: Windows, Linux, Mac, Solaris.

They did that more with the intention of people prototyping their user interfaces on their development environment, because it's easier to make a round-trip on the design and do all your user interface stuff right there on your host machine and then deploy it and test it out. The same is true of SWT. A lot of the development is done on the host environment and then deployed to the target.

So, technically that already exists in NAB. I think what's perhaps different about it is that with SWT and jPhase and then the platform, an entire IDE framework was built on top of that, which lends itself to extensibility. And with NAB, NAB is competing with many, many other Windows-widgeting toolkits for building stand-alone applications.

So, I wouldn't say it's really part of their roadmap to really focus on that, because there are plenty of other people doing that. They really want to focus on the mobile side. And you get the host side sort of as a side benefit.

Daniel: Right, right. OK. Well, what does DD hope to accomplish? And how does it relate to CDT?

Doug: Device Debugging was one of the founding projects in DSDP. It's sponsored by Wind River. There's quite a bit of participation in the embedded tooling space and in the semiconductor space. And the same is true with the Target Management Project. A lot of the same people participant in both projects.

The purpose of DSDP and the reason for its creation was really to take the Eclipse debugging experience to a new level for the embedded space. Eclipse is very, very good at application development, whether it's C++ application development or whether it's Java application development or pick your language, one of the many languages supported.

When you start to move over to the target, there's certainly some good stuff that CDT has done to help enable people on the target side, but the reality is the array of problems that you deal with on target are much more complex. You've got a lot of different operating systems, you have to support real-time operating systems. You are almost immediately into a multi-core situation where you've got to deal with either multiple processors running in SMP mode or running AMP, which really just means side-by-side and communicating over some sort of channel.

You may have DSPs in the mix or SPGs in the mix. And you end up in a complex environment where you may have to connect the multiple things to the target, you've got to deal with the fact that the target responsiveness isn't as good as what you're used to on the host platform, because you've got a limited pipe connection between the target and the host.

You may have different ways to connect, whether it's over Ethernet or a JTAG box or something like that. And so now, your user interface has to accommodate multi-core and task-based debugging and a hierarchy of processes and threads. And you need to keep your keyboard live while you're waiting for data from your target. That sort of thing.

So, DD started out with the lofty goal of saying, well, a lot of us have built very customized versions of debugging in our commercial products, and we had to bypass a lot of the standard Eclipse debug model. Or bypass what CDP has done. And we had to create our own solution to meet the complex needs of our space.

So, let's collaborate and contribute it back. Because it's sort of silly, that part of it is not really a commercial differentiator, and it's silly to have these custom implementations that we constantly have to adjust as the platform evolves.

So the first step in that was to enhance the debug models in the platform itself. And we really couldn't have done this without the platform team. The platform guys, especially Darren Wright from the debug team, got into the project very early on. And he said, "What do you guys need from us? Describe your experiences, describe what your customers are trying to do. Describe what you've done to work around what I've got in the platform, and let's go from there."

And so, we spent a lot of time working on -- probably almost the first year -- talking about that and working through some proposals for changing the platform. And what came out of Eclipse 3.2 was a completely new debug model that you can massively customize based on the capabilities of your debug engine.

Where we are going now with Device Debugging is actually creating a framework that will live on top of those platform interfaces to plug into the typical types of debug engines that you find in the embedded space.

And so we are enhancing the standard debugger views to do things that are unique to embedded development, like bit-field access in re-registers and hardware breakpoints and stuff like that. And then after the Europa release, we're probably going to be looking at different capabilities like multi-core and some of the other things we need to solve in that space.

The relationship with CDT is really, again, it's a pretty tight community here, so CDT, Target Management and Device Debug have a lot of the same people participating. And the people using CDT today, many of them are also participating in the device debugging project with the intention of having what's in DD become the next debugger portions of CDT.

That's something Doug Schaefer's kind of endorsed. He's like, "I really want to see a new debug solution put into CDT that's kind of the next generation." So I think that's where we're going to end up long-term.

The nice thing about having a separate project right now is that you really kind of have a laser focus. You can focus specifically on the debugging task and not on all the rest of the things associated with an IDE first C development.

Daniel: The TM project is really taking off. Can you tell me why?

Doug: Target Management came along and kind of filled a niche that was missing in Eclipse. And it's really just the ability to re-manage remote systems. The ability to access them for debugging, to access the file systems for editing remote files as if they were local, command-line access.

There were lots of commercial solutions to do this. In fact, the basis for Target Management from an architecture standpoint was something called RSE, and it came from IBM's commercial product. That's Remote Systems Explorer. And Wind River had a commercial solution, Monte Vista had a commercial solution, several of the other embedded debug vendors had commercial solutions.

And so a lot of people got together again and said, "OK, we're reinventing the wheel here, this isn't commercially differentiating, we need to come up with something that's standard." And Target Management started to build that.

Since the creation of Target Management, a lot of new use cases -- that aren't terribly unexpected -- but new use cases are starting to pop up. So, people that aren't necessarily in the embedded space, but people who want to do... People who have a remote server that they're developing applications for and they want access to that remote server.

The [inaudible] webmaster, for example uses Target Management to get to file systems on other servers that he needs to access as if they were local. And then he does editing of his scripts and stuff like that.

And Target Management, in addition to having all this connectivity for connecting to remote systems, has sort of a background synchronization capability that pulls -- as you need files on the remote system -- it pulls them local so you can edit them and then when you're done saving them, it pushes them back to their remote system, all behind the scenes. So, it sort of feels like you're working locally on a machine, even though you're actually working remotely.

And then TM has a command line with standard terminal emulation so you can get a command line if you're on a Linux box, for example. And you can do all your standard command line stuff, again, right there in the Eclipse environment as if you were working locally on your local command shell. But it's actually the remote system.

So it's taking off basically, because everyone has needed this, from the embedded folks to the enterprise folks. Everyone has sort of needed something like this to exist in Eclipse. And now we've got Target Management, and the nice thing about it is it's not just a set of tools, actually its real strength is its framework and its extensibility.

And so we've got the standard stuff that you expect for remote management, but the sub-systems can create new connection types and new services and new actions and stuff like that. So you can really customize based on the capabilities of your remote system.

Daniel: So, you've got a fairly new project going, the TML project. What are their plans?

Doug: OK, so, TML stands for Tools for Mobile Linux. It's sponsored by Motorola. It is our newest project. They exited creation review, I think it was earlier this year, if I remember correctly. It was either late last year or earlier this year.

TML was proposed as a way for Motorola to build open-source tooling for Linux for developing mobile Linux applications. Motorola and several other companies in the mobile space are working on a Linux distribution specifically targeted at the mobile space. And they want to have a corresponding tools component, as well.

And Eclipse is kind of, again, the logical piece of technology to start from because there's already so much there. Just take the platform and CDT and Target Management and you've already got a pretty good set of tools to start out, right out of the box that you can start out with.

What Motorola intends to do with this is not reinvent the wheel -- there are plenty of other technologies that work with Linux already -- but what Motorola really wants to do is focus on mobile Linux emulator framework.

So, one of the challenges with developing mobile Linux applications is getting the environment set up so you can do application development of the device perhaps in an emulated environment instead of on the device. And having an environment where you can simulate all the rest of the parts of a cell phone system.

So, all the other devices on the system, the services that the phone is going to access and the network nodes necessary for the connectivity, and TML really want to focus on building that whole emulation environment to make it easier for people to develop the applications. And then they can just repackage the existing technology in Eclipse that's already focused on Linux application development, like TDT and Target Management.

And you've got a pretty beefy set of capabilities for mobile applications.

Daniel: OK. Well, what can we expect to see from DSDP for the Europa release?

Doug: On the Europa train officially are just two projects: the Device Debugging project and the Target Management project. Target Management is coming to its 2.0 release in the Europa time frame, and Device Debugging is still in the incubation, officially. So, it's coming to its 0.9 release in Europa.

Target Management is just using Europa to get to its next version number. The nice thing Europa, as with Callisto, is that it's a process that you can follow to practice the build system and regularly release milestones and follow the IP process. It gets you into a rhythm, a standard product-release rhythm. So, Device Debugging is participating for that reason. And Target Management is getting to its 2.0 release for that reason.

Several of the other projects are trying to do something close to parallel, so NAB is going to have a maintenance release in roughly the same time frame. And ERCP is looking to do their next release as well, which is 1.1, I believe. They're trying to get their 1.1 release done in a similar time frame as Europa.

But they elected not to get on the Europa train because of the extra staffing it takes to go through the processes to the regular milestones. We're hopeful that in the Ganymede train, in next year's train, that we can get more of the DSDP projects on the Ganymede train, but for now we thought we'd start with two and see what the experience was like.

Daniel: Cool, cool. What about beyond Europa? What will we see from DSDP in the future?

Doug: There's a lot of stuff coming down the pipe for all the projects. As I mentioned before, there are a couple of new project proposals that are in the works right now. As they show up, I'll be blogging about them and you'll be able to see them on the project proposal page on Eclipse.org.

I'm hoping to get a couple of new projects started up that are actually in new areas that we're not covering yet. So, I think that's going to be interesting.

The existing projects also have, for the most part, pretty good plans established. Device Debugging beyond Europa -- so, in the Ganymede time frame -- is really looking toward getting to their 1.0 release. Device debugging wants to get out of incubation and have an official 1.0 release. We've already got Wind River depending on the project commercially, and we've got Erickson contributing to the project and getting ready to depend on it commercially as well.

The main piece of functionality that we're looking to add in Device Debugging is a GDB debugger connection, so that there's an entire open-source solution that you can use, effectively mirroring what's in CDT debug today, that people can sort of use to see how Device Debugging works, and see how one connects the debugger to the services framework inside of Device Debugging. So that if you're building a commercial product, you've got an example of how to connect your commercial product.

Target Management has got quite a few things on their plate, actually. They're looking at sort of the standard thing, which is architectural and framework improvements, which is an ever-evolving thing for young projects.

They want to look at integrating additional remote-access solutions besides the standard protocols that are supported today. They want to look at some of the more interesting scenarios that required for device software development, like multi-core.

Target Management is sort of poised to create more complex launch scenarios. Like, in a multi-core environment, you might have multiple targets that you want to start at the same time, and you need to do hardware resets on them and set up registers and download code and then kick off the code.

In Eclipse, you can kind of get one launch to do something, and so companies that support multi-core typically have to pack a lot of stuff behind the launch infrastructure to create that. Target Management wants to create something called "launch groups, " which allows you to link a lot of launches together and then actually do a coordinated launch effort in a multi-core environment.

You know, we're thinking about this from the embedded space, but clearly, you can imagine multiple processes that you need to kick off on a server or something like that, that would also benefit from a concept like a launch group.

And then I guess, finally, Target Management's looking at remote lab management. So, again, something for test environments where you've got a lot of remote systems that people have to reserve when they want to use it, whether it's a server system or a supercomputer or just a board lab full of embedded targets.

Lab management is something that Target Management has as sort of a natural fit for. So they want to provide some hooks for remote lab management, even if for the technology, they don't have a full solution in the Ganymede time frame.

Moving on to Mobile Tools for Java, they've got a pretty well-established plan in place. So, they're not on the Europa train, and they're really just hoping to get to 1.0 later this year.

They've really focused on the build and emulator frameworks as part of their first, their 0.7 release, I believe it was. But they want to complete the capability set for the UI editing and remote debugging and remote launch and deployment and stuff like that. They want to finish out the feature set for 1.0. Their current goal is later this year.

ERCP is really about extending the libraries to other platforms. Their current roadmap really has them... Nokia Series 60 is the main thing they're working on right now. They're seeking contributions from the community to try to get it on Linux.

One of the big areas that's missing with ERCP right now is a port to both Linux GTK and Linux QTE. And I think they're really hoping to get some interest in the community to try and port the ERCP runtimes on Linux. That would really expand the possibilities for deployment for ERCP.

Native Application Builder is also in incubation, looking to get to 1.0. They have a great community in Japan already that's been using the Wide Studio technology in NAB already. And I think their main goal is to try to expand that community out a little bit.

Because in order to get to 1.0 and get that first release review, you've really got to have all of your communities really established, and that's NAB's challenge right now. They have a very mature technology, so it's really just about getting more people to adopt it.

And then, finally, Tools for Mobile Linux. Like I said, they're a fairly young project, so they've really just got a lot of code to write. They started out with the intention of looking at the entire mobile Linux development life cycle and they've focused in their scope now on the emulation environment and emulating the sub-systems around it.

There is some talk right now on the TML project to try and move beyond Linux actually, and talk about general mobile device emulation. There's some interest from other companies that have been talking to TML, like Synergy, who aren't' using Linux but want to have the same types of capabilities in Eclipse.

So, TML is thinking about re-scoping and trying to solve a more general problem around device emulation, mobile device emulation. And as with other of the incubation projects, they're working on community growth.

Daniel: Any closing remarks?

Doug: I guess the standard closing remark I like to say is: we have a lot of things we want to do, and like most Eclipse projects, we need participation. So, we're always looking for people who want to step up and help out. I guess if you're listening to this, and any of these projects sounded interesting to you, definitely introduce yourself on the newsgroup or the dev list of the corresponding project.

You can start with just someone who want to try out the technology and offer advice, or file bugs. And you might move into testing. You don't have to go right to contributor, where you're developing code. A lot of people get put off with having to jump in with both feet.

But a lot of the projects could really use that, to grow faster. So, I guess that's the one thing I would say.

In general, I think, we're always looking for new project ideas. And it seems like I probably get one or two ideas per year now -- since the DSDP was started -- about new ideas they want, new projects they'd like to create. And I think it's great, and I sort of want that to continue.

Not everything has the potential to be a full-fledged project, because there's overhead associated with running a project, and it's not necessarily a way to incur that overhead. But device software and mobile space covers a lot of different technical areas, and I'm very interested in getting ideas from other people about things they'd like to see Eclipse do.

Daniel: Excellent, excellent. Thank you for joining us, Doug.

Doug: You're very welcome. Thanks for inviting me.