William Cook, Moderator: All right, thank you. If anybody wants to paint the picture of where we are going to be in 10 years, I'm going to give you a minute to do that.
Bob Walker, Gemstone Systems: What we found since we're already doing transparent access to objects without having to do anything other than to say "Wait or I want an egg" and the egg is still there. I think that problem has been solved in terms of OR mapping or impedance mismatch, I like your analogy, I think that is very good. I think the next step and from what I'm hearing from programmers, I hear things like "I just want my objects. I just want them here and I want them now and I don't want to have to mess with it, I just want them there, I don't want to have to deal with the database, I want all that stuff taken care of for me."
I think the next step, and I think we're seeing this at Gemstone, is what basically is a distributed in-memory live object cache that has transactional attributes but it doesn't deal with disk space storage what so ever. I think, five years from now, we are going to memory cheap enough and fast enough that there won't be any discs. There will simply be in memory objects, ubiquitous throughout the enterprise, a robust sea of objects always available for the programmer. They don't have to mess with OR mapping, they don't have to mess with object databases, they don't have to mess with SQL, the objects are just there ready for the taking and for the use.
William Cook, Moderator: Great so we have a convention. If you agree with that, you can just say "Gush!" I completely agree with everything and I don't need to say it again. So if anybody wants to agree with that they can and if anybody give a different view.
Derek Henninger, Progress Software: So I'll "gush" -- but I think "Fine there is this distributed object caches in memory, great"each object application, even two applications of the same domain, often have different object structures. There's going to be transformation required between that. I completely agree there's significant transactional characteristics that are going to be associated with that, that need to be managed and I think it's our responsibility to satisfy that and the needs of the programmer and to make that simple and easy to use.
Beyond that, I still think that the relational model and other data models are going to exist for 10 years. We've been saying that some of these mainframe database are going to die and they still sure as heck haven't. That kind of mapping and transformation into the objects in memory representation is going to need to occur and you're going to need to do it in a way that does not impact those legacy applications that nobody wants to touch. Those Cobol programmers that we talked about so affectionately earlier, those guys don't want to touch their applications. You do something that affects their application logic, and keep in mind those old Cobol applications make a lot of assumptions about what the transactional characteristics are of the data they are managing. So there's a lot more complexity to it and I think the mapping is a key part of that.
Robert Greene, Versant: I've been stuck with that recurring dream myself but I would tend here to side with Erik. You're not going to get away from the realities, of having to worry about the transaction nature of your logic and also the raw scale. When you start talking about dealing with information which is in the terrabyte and even approaching the petabyte rangeyou're gonna be hard pressed to blindly deal with that it's that there are just objects that are available. You're going to have to have new constructs that are either built into the mapping and transformation layers or natively in the language, that can help you as a programmer to deal with those things and its transparent way to possible, but I think it'll never be completely transparent -- at least not in my lifetime.
Erik Meijer, Microsoft: I think it's a delusion to ever think that all your data will be available as objects. Over time there will be more and more data models and forms of data MP3s, audio, video, whatever. And you want to deal with all these forms of data, you don't want to get stuck. So the only solution is to look for something that very much rises over all data models. And there is a solution for that, it's called "Monads". This was invented by the mathematicians in the 1920s.
But if we look 10 years from now: I'm going to make a little digression here because I was judging the students competition and none of the students told me "My work is impractical and maybe in a hundred years there will be a use". But if you look at this theory of Monads that was invented by mathematicians in 1920 or something: They had no clue what this was useful for, so my believe is that in 10 years time we will be in a crisis because the current generation of students are only into impractical stuff and they're not generating the theory that is necessary to produce the kind of next generation technology. It's like oil, we're running out of mathematics quickly. This is my sober view of from 10 years now -- it's sad.
Christof Wittig, db4objects: My prediction of what is going to happen in 10 years is sort of a cultural war who owns the data. Will be the side in one way or the other -- I don't want to make a prediction in which way. Actually, the fact is that in enterprise applications the data belongs to the DBAs and not to the developers. I think that it's time that developers reclaim their territory. That's why we have so much traction in the embedded space which is also dubbed as zero administration -- lack of DBAs. But we should think a little further and take ownership of the data persistence. And that's where I disagree with Craig. It does make a difference whether your meal comes in 10 minutes or 10 hours -- a developer should care about this. Even if the API is the same -- he has a menu and a bill to pay in the end and a meal in between -- it does make a difference whether it takes 10 minutes or 10 hours.
Also the quality: Can I properly persist inheritance, can I properly really persist the power of object-orientated languages. The fact is that these kitchens that we have to date don't allow and cater to those needs. So we have to reclaim those territories and put ourselves in charge.
What works well in the embedded space, I think will very well be picked up with service orientated architecture in the enterprise space where the application, the database form a contained silo and no MIS consultant will ever touch the database but only use the predefined service gateways which are ownership of the developers themselves.
Patrick Linskey, BEA: I guess to that I'll say "Gush". One of the things that Eric said is really interesting. I think you'll see a lot of different types of data models coming out. I think the next one we're going to see in the next 5 or 10 years is this kind of this concept that we were talking about earlier, of data grids and data in the network, like data on the cloud rather than data on the little disk.
All this different new modes of data storage and data durability are going to end up demanding different APIs and different ways of interacting with them. That is definitely going to make things more interesting. But I think that also 10 years from now we're going to use a whole set of new languages. No one is going to use Java, no one is going to use C#, everyone is going to use Dflat and Cava or whatever. We always do this: We throw away all the knowledge we learned and start from the scratch again. And I think 10 years from now we'll be going to do that again. We'll have the same discussions about what's the right way to do it, what's the right way for the IDs and what's the best storage. We'll probably disregard the past. That's not what I hope happens but it's what I think will happen.
Craig Russell, Sun Microsystems: I'll just say that I really "gush" about the fact that the big crisis coming is about who owns the data. Is it going to be the people who produce the content or is it going to be the people who distribute the content? The digital rights management I think, we haven't seen the third act or the fourth act play yet and that's going to be somewhat critical. What I do know is that the date you know who owns it, the in the corporations, and the people who pay the piper which is the corporations, there'll be a significant number of those who demand very fast access to the data and the higher programmers who can deliver that fast access.
I'm sorry because in my analogy I didn't carefully enough recognize these staff and the people in the kitchen in serving this meal. I do recognize that a good presentation is a well orchestrated operation involving a whole, serious people from the backend, from the people who actually order the meals, order the raw materials and prepare the meals to the people in the backoffice accounting wise who magically transport your plastic and deliver you the key to the exit door because you don't leave without you pay.
So there's a lot of roles going on in delivering persistent data. I'm in describing what my focus was: To deliver the ultimate dining experience. I recognize that there's some on the panel here who are more involved in the back office kinds of operations.
My vision for the future is ubiquitous data, but the data is as distributed as varied and the ownership varies with the data. To the point of all accesses aren't in this particular style. The needs of the cellphone or the PDA are very different -- I completely agree with that -- and I don't want to eat my chicken cordon bleu with a cell phone.
