8 - John Graham of the DTP Project

[intro music plays]

Riyad Kalla: Welcome to Episode eight of 10 of the Eclipse Zone Callisto podcast series. I am your host Riyad Kalla. In this series, we are interviewing key members from each of the Eclipse Callisto projects that will be included in the Eclipse release. Today we will be interviewing John Graham, who is a part of the DTP Project. Thanks for joining us today, John. Why don't you start with you giving us a description of what the DTP project is all about and what role it plays in Callisto?

John Graham: Thank you. Thank you, Riyad, thank you for having me here.

Riyad Kalla: Sure.

John Graham: Yeah, the DTP Project is Eclipse Data Tools platform project. It a relatively new top-level project at Eclipse.org. We had the proposal for the project just before Eclipse Con 2005. That's when the proposal started. We went to Eclipse Con 2005 and quickly built a very strong community, which included people from the Web Tools platform project and people from the Business Intelligence and Reporting Tools project, amongst a number of other groups that expressed an interest. So, we are very fortunate that we started with a very experienced community and also a lot of code. So, one of our initial challenges and we did this mostly last summer and into the early fall was to take the code and understand all of the contributions, what we should use and what we were going to swap out and how we could integrate the pieces that we had. And once we did that, we did an initial release. We had the release candidate available at Eclipse Con this year and just after, like the week after the Eclipse Con, the actual DTP-07 release came out. So, that was out for the release and was really for us to get this code consolidated and working together and providing a basis to go forward with. So, the Eclipse Data Tools platform project is, as the name implies, a data tooling platform for building data-centric applications in each Eclipse.

Riyad Kalla: I see.

John Graham: So, databases are one good example, but it's not just limited to databases.

Riyad Kalla: I see. Now, you mentioned that you guys created a project to propose at Eclipse Con last year, and got BIRT and WTP on board. Was it that the DTP project formed and then you went and said, "Hey, who is interested?" Or did you talk to people and they said, "Hey, we need this" and then the DTP project was formed? How did that work?

John Graham: Well, from our side, speaking from my experience, and from my host company Sybase's experience, the Foundation itself in the form of Mike Milinkovich and Joran Dansen was actually out talking to the community, hearing that, "Well, we have pieces of data-type tooling and data platform tooling scattered throughout Eclipse.org, and we really need to have a top-level project that consolidates this and drives it forward because it's a very important part of the Eclipse ecosystem." So, I think that they were hearing that and they came and they spoke to me about it and we decided that it made a lot of sense and it was something we wanted to be involved in because, you know, we also had some tools in that area. So, we started and we kind of knew because my product team has been building products on eclipse since Version 1. So, we were very familiar with the history and all the projects out there. So, we kind of suspected that WTP would be very interested and that BIRT would be very interested and so, it wasn't entirely a surprise for us, but you know... Yeah, it's been a very interesting learning experience as well.

Riyad Kalla: And you said, you got involved because some of the Foundation members came and spoke to you. Did they proposition you with the idea of a project or did they say, "hey, we need this" and the Sybase team came up with the DTP project?

John Graham: We knew them from before from having worked on a variety of Eclipse Cons and events and from having been to the Eclipse cons, so we knew them pretty well and so, being a company that has a strong tradition in databases and data management and data tooling, they just more or less came to us for advice. They said, "We are hearing these sorts of requirements out of the community. We think this coalesces into a something like a top-level projector maybe a technology project or subproject somewhere, we don't really know. But these are the sorts of things we are hearing. What do you all think?" So, then that's what let us to come back internally here and have this discussion. And we did talk at that time to members to WTP and BIRT and we eventually came up with what was a top-level project proposal with the three initial projects: model base, connectivity, and SQL dev. So, really the Foundation brought us sort of general feeling and requirements from the community.

Riyad Kalla: I see. Well, now, we have the Callisto release DTP, which you pointed out to me was the 0.9 release, but in some of the documentation online I saw, it was referring to it as the 1.0 release. So, can you clarify for us, what was the 0.9 release and when is the 1.0 release coming?

John Graham: Sure. Right, right. At Eclipse.org, it was just after DTP was proposed. You know, at eclipse.org you do a proposal and that goes through the usual phase with the community and then you do a creation review and if you pass that, then you start as an official project. So, just around the time when we were getting ready to do our creation review, the Foundation was refining its development process to include the notion of an incubator project and mature projects, similar to what some other open-source Foundations do as well. So, moving from an incubator to mature is actually one thing and that's getting a 1.0 stamp. So, that's a signal of moving to a mature status from a point release. So, the intention is you go into this phase after project creation, where you build all your project and you do one or more releases to get the initial code out there and then begin to build a community and begin to build the foundation, prove that your project is viable and that has all of the pieces in place. And then, once you are there, then you go through what is called a "check point" review, as part of another release, and if the community agrees with your feeling that you are there, you then move to 1.0 status, a mature status. And this is a slightly new process. Like I said, it came online just when DTP was starting, so we decided we'd really like to follow that because we really like the incubation model.

Riyad Kalla: Right.

John Graham: To make a long story short, we did our first release and we were very aggressively targeting a 1.0 time frame for Callisto, but what Callisto turned out to be, was learning a very valuable lesson about how to work with the other Eclipse projects, how to synchronize and build in a way that they can consume and build in timing that they can consume, and package features, and so on.

Riyad Kalla: Right.

John Graham: So, probably 3/4 of the way through, the top level management committee for DTP, the PNC got together and we discussed it and we felt like we went through the validation check list, as it were, and we felt like we were basically 95% of the way there. And there was only a couple of items, like we would like to get a couple more documented adopters, using DTP... At that time, we had only one or two. We wanted to get a couple more. We also wanted to refine our provisional API statements a bit more and we just wanted to darken the DTP more. So, it wasn't so much a feature or quality decision, it was more supporting infrastructure. So, it was a hard decision to make because we could have gone either way because we were so close and we asked EMO for advice and they kind of said, "Yeah, you are really close and these are areas you might want to look at, but I think you are really close." So, it was kind of left to the PNC and we talked about it at length and we decided to err on the side of caution.

Riyad Kalla: Right.

John Graham: So, we said, "We really want to follow this. So, when we say 1.0, we are going to mean 1.0. We are going to mean that we are mature and solid and we have all these boxes completely checked off with no questions." So, we decided to go for a 0.9 release at that point. And this was fully supported by the community. You know, we explained our position to the rest of the Callisto projects and I don't want to speak for the other projects, but the general sense I got was that, "Oh, you don't have to do that, but if you are going to, that's cool. We are fine with it." [laughs]

Riyad Kalla: I see. Now, talking about the Callisto projects, the Data Tools is working with. You mentioned BIRT, WTP, and we've done interviews with WTP and they mentioned big collaborations with DTP. What is the day-to-day development like? Is it that you guys cannot make a change until the other teams have looked at it because it's such a tight dependency or do you just do your daily work and then show them what you have at the end of the week and they say "yeah" or "nay"? What's that relationship like between those projects and DTP?

John Graham: Yeah. Well, I think it's a little bit of both in the sense that we do have planning. So, we use Bugzilla, we use the news groups, and the mailing lists in general discussions with the community to try to understand requirements and, of course, collect bugs and everything like this. And then our project leads make plans and they post plans. And then they go and make changes and anything that might impact downstream consumers, they are very careful to send a mail to the mailing list to say, "We are planning to do this week. It could this impact. Let us know if there is any concerns." And then we make the changes. So, in general, integration with other projects, people are all aware of where we are going before we are going there and they have ample opportunity to speak up. Occasionally, sometimes something slips through the cracks. Maybe someone did not see an email or they did not fully understand the implications or maybe we didn't explain ourselves well and so there's this sort of a reactive kind of thing, where we help people. "Oh, now you are broken here. We'll help you over the hump." But overall, I think the Eclipse Foundation has a lot of good experience in best practices around this sort of a thing. Part of working with Callisto, one of the joys of working with Callisto, was to learn some of these by working closely with other projects that have been around for a while. So, we are just trying to adopt the practices that they have to avoid needless rushing and in this manner.

Riyad Kalla: Is that where your to-do lists are coming from? From other projects that want to use DTP or do you guys a have a year or two-year game plan that you absolutely want to hit already?

John Graham: Well, we have. I mean, we collect requirements from a large group. And of course, SYBASE is building commercial products based on DTP. In fact, they released it now. You can get commercial product from SYBASE that has DTP built into it. So, we are getting from the internal product teams files of requirements, requests, and so on. And there are other adopters out there as well. We have a community page on the DTP website, where we mentioned Sybase, we mentioned BIRT as an open-source project, and then actuate as a commercial project. So, there's a little link there. And there is a number of others coming now. As you can imagine with products, there is some timing and some confidentiality, so not all of it necessarily appears on the web page until products are ready to talk about these things. But, overall, we get lots and lots of requirements from news groups and mailing lists and from other forms. We do consolidate all of these to Bugzilla and to the mailing lists so anyone in the community can see the requirements that are being brought and discuss them openly even if they come in a private email or conversation. They are pushed out to the public forums.

Riyad Kalla: I see. Now, is DTP trying to position itself as an end-user tool like Graphical Query Builder and things along those lines or is it trying to position itself more like a tier 1, almost like EMF: many projects utilize it, many projects build on it, but so much an end-user tool?

John Graham: Right. Well, I think in the case of something like EMF, it's a little bit easier to say "Tier-1 dependency" platform. It's a subproject and it has a relatively smaller scope in terms of... When you go a top-level project at Eclipse, because a top-level project is an aggregator for other projects, we have some like model-basing & connectivity, very much platform-centric and framework-centric. So, these are primarily for adopters and people building our platform. Although, there are some UI tools in connectivity they are really there as examples of how to use the platform. But the SQL Development Tools project is more an end-use. Even though, there are platform bits in there and frameworks in there, that tends more toward the end user. We expect going forward to have a healthy mix of those two approaches. I think currently we are more platform, which I guess is a result of getting the basics down first, but going forward I hope we have a healthy mix between end-user tooling and platform tooling in DTP. We will be a fairly large project with lots of participants and lots of ways of approaching it.

Riyad Kalla: Ok. Can you give me an overview of the model base and the connectivity projects? What are their goals and what kind of user should pay attention to those projects?

John Graham: Okay. Well, the model-base project is actually an aggregator. It's the collection project where we put all of our domain models. Now, when you hear "model-base", the thing you want to think of is EMF model base rather than data modeling. A lot of times people hear "data tools model base" and, therefore, that is the data modeling project. And that's not the case at all. We have a number of EMF models, one that represents SQL, one that represents SQL queries, abstract syntax trees and such, some that help you out with XML as it interfaces with SQL. Some that are general database definitions for things that are vendor-specific. So, we have a number of domain models for data centric applications that are built using EMF technology and rather than scatter those through the other subprojects and have crossing dependencies and lots of trouble and confusion, we decided at the beginning to put those all in one place. And also, the committers on that tend to be a cohesive group who all work on the same sets of models. So, it made sense to consolidate from an operational and functional perspective. So, model-based is really the domain models for DTP and for anyone consuming DTP.

Riyad Kalla: I see.

John Graham: Now, connectivity, its primary function is to provide connectivity data sources. We defined DTP very broadly as working with data sources not just databases or relational databases, but data sources. We chose to focus on relational databases in the short term, although if you look at some of the open-data access components that originally came from BIRT, they work with flat files and, of course, BIRT works with many other data sources other than simply databases. And the common thing in interacting with data sources is that you typically need to define some sort of a driver that lets you get access to the data source. For Java, it's typically JDBC drivers, right?

Riyad Kalla: Right, right.

John Graham: So, we have a driver management framework that lets you define these drivers once and for all in the Eclipse platform rather than to have you define them every time you make a connection for the tool. It's global to the Eclipse instance, so any tool can use those driver templates and leverage them, and then users can organize them. So, there's that framework and those examples as well, and then just the ability to take driver templates and instantiate specific connections do a data source. The idea is, how many times have you downloaded a bunch of different plug-ins into Eclipse and then you want to make a connection, say a database, but each tool forces you to type in all the details. And you say, "I already did this once. Why doesn't this other tool know about it?" Well, one of the things we are trying to get away from is by doing the connectivity, if you all feed off the connectivity, then the user says it once, and then all the tools can use that and also, then you can share connections and so on. There are a lot of benefits for centralizing from this functionality. So, the connectivity framework gives an abstraction over the notion of connection. So, it could be a connection to a database, a flat file, to a queue, to a stream coming in over a hardware device you might have, whatever it might be. The open data access components, the ODA that we got from BIRT give an abstraction in a similar fashion over the type of data you get. Are you getting relational data, are you getting binary data, our you getting pure text data? So, open data access gives you a standard way to access a type of data that you are going to get across data types whereas the connectivity labors underneath open data access, gives you a standard way to access connections to those data sources.

Riyad Kalla: I see. Now, working our way up, let's talk about the Enablement Project before we get to SQL dev tools.

John Graham: Okay. So, one interesting problem that we ran in to in DTP and it's not that we were not aware of this problem, it's just I am not sure we really understood how deep the problem was going to be and how we were going to handle it eventually was that because DTP is platform-centric and we are providing an abstraction over connections and data types in the most general sense, you can then reasonably imagine you download and try to connect to say, database X, Y, or Z. Now, we need as part of the Eclipse model, what you do is you provide a platform or a framework, and then provide exemplary tools to show how you build tooling off of that with the expectation that it extenders will come and use those tools, and maybe create their own tools. We chose to use the Apache Derby database as our sample database because it is open source, native Java, and well understood by our committer base. So we chose to use that. So our tooling works really well with Apache Derby, but that doesn't help you if you don't use Apache. Derby. If you use another database the connectivity, because it relies on pure generic JDBC functionality and a lot of databases have out of band or proprietary information, metadata that you need to know about to get the full view of what's in the database, you end up with a disconnect. So everything was built from the beginning so you could actually go and just specialize the model, make your own connection profile and just use all of our base classes and extension points and everything, and then build out specialized data source support for any particular database or whatever else you might have. So that's all there, but naturally if I'm an end user and I'm interested in building a tool, I'm not particularly wild about having to rebuild all of the stuff from my particular database. I'd prefer just to have it. So this is the problem, this is what I blogged about, I called it the device-driver problem. We're kind of like the operating system vendor and now we have all these potential devices out there and we have to start writing device drivers for every one of them. And that's just a lot of work, and it requires a lot of expertise that we might not have immediately available to us. So one thing we could do is just throw it out to the community and say, "OK, maybe someone will do this, maybe it will be open source, maybe it won't be, maybe freely downloadable. Whatever. But we wash our hands of it." Well we didn't think that was a very satisfactory solution because we'd like to have things closer to DTP. We'd like to have things available using EPL and the Eclipse IP policy so you. Could go and download DTP and also download specialized datasource support for. The enablement project that has gone through the same IP policy reviews and everything so you know exactly what it is you're getting and it's readily available right there on the DTP site. So, therefore, we establish the Enablement Project, and we're encouraging vendors and other groups that concentrate around specific datasources to come to us and to put committers on that project and to specialize DTP for that. So in the initial proposal we showed SYBASEfor SYBSE databases, IBM for IBM databases, and Accuate for an XML datasource. So here we have, again, some more relational database support coming in, but also another datasource, an XML datasource. So we expect to have that stuff rolling in. And we're talking to the community, in a very broad sense. I think Jay Pipes from MySQL has mentioned several forums and blogs about MySQL being entrusted in the Enablement Project, and coming forward and working on that. We're trying to encourage a wide community for the benefit everyone so that way whatever datasource you use you can download DTP and it works very easily with it. Sot that is the Enablement Project.

Riyad Kalla: Now we've talked about all the underlying, the foundation. So listeners using it are going to want to know where is the database explorer, where are these types of things, where is this visual SQL designer I was reading about? So let's talk about the SQL devs tools now.

John Graham: So the two qualifiers in front of that are the adjectives for it, SQL. So it's about SQL, and it's developer tools or development tools, Depending on how you want to read that, we just call it SQL dev. It's really developer-centric SQL tools. So we have your standard kind of thing, your basic SQL editor that gives you code completion and so on, parses and you can execute statements. We have a results view so you can see the results come back and see what's going on. We actually have a script history so you can go back and see the scripts, the SQL statements you've run, then you can rerun them and so on. So we have a number of really kind of standard, expected type tools, that you would usually do if you were a developer. So you're a Java developer or a C++ developer, C developer, whatever, and you're going to write some SQL and maybe want to test it out against your database before you embed it in your connection. Well, there's the tools, so that's the base and that's what you see. Now mind you, even though these are SQL development tools, they still have a number of frameworks, there's an editor framework, and we've only put the basic example editor on top of it. You can do a much fancier job if you're a product or an extender, based on the editor, or rewrite your own. But again it's a framework-centric approach.

Riyad Kalla: Is this the SSE editor framework from WTP or something else?

John Graham: Well, we're not actually using the SSE framework from WTP, the example. Editor just uses the standard text editor framework stuff that you get in Eclipse. So basically you're using partitioners and scanners, and the colorization mechanisms that you get with the Eclipse platform itself. Now you could, of course, take our editor's underlying framework which doesn't have the actual UI editor, and then use SSE from WTP and implement something more complex. That's always an option. We didn't do that, but you could. Now there are things that go beyond that. For instance, support for routines, by routine debugging. By routines we mean stored procedures, and user defined functions in databases. So we have a framework for that, we have an execution plan view framework, we have a proposed visual SQL query builder.

Riyad Kalla: Tell me a little about the visual SQL builder. Is that like the type of thing where I would expect to be built on top of VE, or is it something else?

John Graham: It's actually something else. VE's purpose is to build SWT, well not. Solely but to take the Eclipse example, to build an SWT form or a dialogue in a. Visual metaphor like you would with Microsoft Visual Basic for instance, a visual query build is a little different animal. It basically says give me a representation of the tables that I'm looking at, and let me grab fields and say, "I want this and I want that and I want to put this condition on it." Basically what you're doing is it's a fancy way of writing SQL. It's a fancy way of writing SQL statements, in particular queries, but it's done graphically. So it's a lot easier because sometimes you might not remember all the call-up names, and it can do that. So it's really not about creating a UI form it's about creating statements that you can then execute against a database. The current status of that is that we've had that in our proposal. IBM has a visual SQL query builder that they've offered to DGP, and they're in the process of sort of, how should we say, componentizing it and preparing the code for the initial donation. So the code's not there today, but we're hoping in the near future that that will come out. And it will probably come out in more of a monolithic fashion in the sense that it will be a visual query builder. We'll then work with support from the community to make it really extensible so you can take it and maybe you don't want to do SQL. Maybe you want to do something else, some other query-type language, and you could actually build on that, maybe you want to extend it in various ways, maybe you want to do fancier diagrams. So we want to make it so you can be extensible, highly modular so you could take off the pieces you want. But that will be ongoing work, right now. We're just working with the idea of internal teams to get it to a stage where we. Can do the initial code drop and try to get that out as soon as possible. As you can imagine when you take something out of a product, or that had a life in a product, it takes a while to get to that state. But we're very encouraged we think this is going to be a really excellent edition to DTP and we're looking forward to that contribution.

Riyad Kalla: Now, in addition to the editor, the visual builder, you mentioned the routine debugger framework. How does that work? What kind of features does the underlying database or datasource need to support in order to function? Is this like a real-time debugging or is it interpreting a script and running it inside a DTP?

John Graham: Well, interestingly you could really do either of those options that you just mentioned. Because the debugging capability tends to be highly implementation specific some databases will have this some might not, and then even amongst those who do, the support will be varied so, really, the debugger framework is an abstraction across what it could mean to be a debugger, and then you plug in your implementation-specific components underneath it. Now, what this actually buys you is a standard interface into the rest of the tools that you get with DTP. So it can actually work with the rest of DTP. So to take an example of Apache Derby, stored procedures in Apache Derby are typically written in Java. So if you take a look at a stored procedure in Apache Derby you quickly notice that there's a Java function call, you know ok here's a class that is stored and executed against the database. So you could imagine a really simple implementation running as Derby would effectively delegate calls to the JDP debugging components that you get with Eclipse because that's the implementation specific one. Now you say, "Well, we already have that in Eclipse." Well in that case you do, but there's no need to rewrite all that stuff. Now having said that the debugger framework in DTP narrows a lot of the. Interfaces that you get in the debugger framework in Eclipse, so they're very similar. So if you're familiar with one, the other, the DTP one is very easy to understand. But that's just the case of Apache Derby. Another database might have a different way of doing it so you would have to write more code and implement it. But it's really just an abstraction layer so the tools can talk in standard way to the implementation-specific stuff. So that's what the debugger framework's about.

Riyad Kalla: I see. So right now Apache Derby has the support. Is there upcoming. Support for Microsoft SQL Server or MySQL?

John Graham: Well that would really be up to the enable project. What we would hope is to take the case of MySQL, when they get ready and they come onboard with Enablement, the first thing they'll want to do is take. There's a base MySQL model, which gives you a basic tree in the datasource explorer for MySQL, but it doesn't give you all the objects in a MySQL database. So we would hope that they would pick that up and they would sort of finish off them all specializations so you can see a complete representation of a MySQL database. And then they'd probably create a standard connection profile because that lets you set parameters and values by default so users don't have to type in things that you can predict. And then once you're done with that you say, "Okay, well what's next?" Well, one thing might be, "Okay, I want to go in and I want to enable. I want to put in an extension. I want to contribute to the extension." Points in the debugger so now I can actually open up and debug into MySQL and that would be a great contribution to the project. Whether they're going to do that or not, we haven't had the discussions to that depth, but that would be an excellent candidate for that.

Riyad Kalla: Now what features should users be aware of in the Callisto release or even the 1.0 release of DTP that you all have coming up.

John Graham: Right, now, the Callisto release, in my experience developing software I sort of categorize software releases into a variety of types. Like feature releases concentrate on adding new features, you might have a quality release. That concentrates on cleaning up bugs and getting to a certain level. So the first release, the 0.7 release, was really a baseline feature release, to get the core stuff in there we needed to just make anything work. And we got a lot of features in there and quite nice support. The 0.9 release that went out with Callisto was really kind of two things. It was to clean up any bugs that we found in the meantime and also a synchronization release to learn how to build and work with the dependencies. So we concentrated a lot of our time, like we refined out feature definition, our feature being Eclipse features, the packaging of plug-ins, by discussion with the community and just basically bringing the packaging and the distribution of DTP in the update site to a mature phase. So that was Callisto. Now coming out with 1.0 we're looking for contributions in the Enablement Project, which will be very exciting. We're hoping, and again this is going to depend on timing a lot, but we're hoping maybe we'll have some form of the query builder out for the release folks to look at. And there's a number of incremental features that you can find to improve, like add certain menu items, add toolbars, add some more end user documentation perhaps cheat sheets and stuff to make it a little bit easier to understand how to use our tools and so on. So if you take a look at the Bugzilla entries, the enhancement entries, our teams have been going through in the past couple weeks and making sure those are up to date and putting target milestones on them and everything, you can get a sense of some of the incremental features. But also to get to 1.0 we have to make sure we clarify our API statements, that we make sure we have all the unit tests that are necessary because we have a quite a few now. But we just want to make sure we cover all our bases, and the end user documentation is an important part of that too. 1.0s really concentration on getting those other bits to graduate to mature status wrapped up in addition to adding these features in that I spoke about.

Riyad Kalla: I see now, 1.0 you're talking about a late fall release, aren't you?

John Graham: Q4 probably more toward Christmas.

Riyad Kalla: Okay, so then Europa is next year. Is the plan to have like DTP 1.5 in Europa, or is that too far off to see it?

John Graham: No, no, something like that, sure. I'm not sure if it'll be 1.5 or 1.7 or what not, but, yeah, they'll be another 1.x release in Europa, and that, again, will probably have more features. But Europa is effectively what we did in Callisto with more projects and more dependencies between the projects. So there'll be an additional learning curve to integrate the dependencies and to try to build in a little tighter cycle. DTP currently has a fairly static amp-based build system that we just kind of built out as we went along, and. We're going to try to migrate to the dynamic Eclipse-based builder that's used by obviously the Eclipse platform, but WTP, for example. Some infrastructure changes but this will help adopters who might want to pull down DTP and rebuild it for their own platform in a standard way, or maybe modify it and rebuild it. So there's a lot that goes into a project at Eclipse.org other than features or bug fixes, but a lot of supporting infrastructure around it that needs to be addressed as well.

Riyad Kalla: Yeah, absolutely. Well, John we're getting to the close of this podcast. Is there anything you wanted to add before we signed off?

John Graham: Well, what I'd just like to say is that we've come up with these two. Releases of DTP and we've build a pretty strong community around it. But I'm very encouraged. I was just on the west coast this week talking to a number of adoptive communities and planning with the PMC. I regularly give talks at conferences and such, and I'm really beginning to see a very wide and deep interest in DTP from a lot of different sources. I think this is a great time for people to come and engage DTP. We're at the stage where we have the foundation in place, and now we can take this thing and move it up to very interesting levels. But, to do that in a way that maximizes benefit from the community we need to dialogue with the community. So we do have quite a bit of traffic on our newsgroup. We do have quite good traffic on our mailing list and everything. But I encourage folks to come out and talk and say, "This is what I like, this is my vision of what DTP could be." I mean, not always can we answer these questions with quick answers, or say, "We promise to do that for you," because ultimately DTP can benefit a very large number of people but we need that interaction with the folks. So I'd like to say to folks, this is a really good time to start to get involved in DTP, a way to drive the future direction. So I would encourage people to come out and talk to us. I think you'll find we have a relatively small project team, but a very committed and easy to talk to project team I think as well. So please come and talk to us.

Riyad Kalla: All right, and the project is ambitious as well so the more people helping out with use cases and requirements and features everyone benefits because, like we mentioned before, it's becoming a dependency for so many projects. Well, we wish...go ahead.

John Graham: Sorry, I was also going to say, too, in terms of contributing to DTP, registering bugs is an extremely valuable service, sending patches to us is very valuable. Becoming a committer doesn't mean 40 hours a week. A committer might mean a couple hours a week a month or a couple hours a month. But all these contributions are extremely valuable. I think sometimes people are scared away from engaging more deeply because they think they have to give 40 hours a week to it and that's not the case. There are many levels of contribution to it, and we welcome all of that and I encourage folks to come forward.

Riyad Kalla: Well, John, I wanted to thank you for sitting down and talking to us about the DTP project.

John Graham: Well, thank you. It's been very nice talking to you and I appreciate the opportunity.

Riyad Kalla: Absolutely. Well, we appreciate everyone else tuning in and hope you enjoyed yourselves. This concludes episode eight of 10 in the Eclipse Callisto Podcast series.

[Music]