resources | lerman & hopper, 1992 [research interview]
Steve Lerman & Mary Hopper, Passages from Personal Interview, March 4, 1992
Passage 1
Hopper: Eventually new generations will be needed, the question is how much longevity can you get out of it?
Lerman: It is important. Between AthenaMuse 1 and AthenaMuse 2 there will probably be a break in compatibility. AthenaMuse 1 was a research prototype. It was not architected in any formal sense. It was built in pieces and we wouldn't want to live with it forever. AthenaMuse 2 is intended to have much greater longevity. Not infinite, but substantial longevity. Our development plan calls for creating an initial version of AthenaMuse 2, and then having an annual upwards compatible upgrade for at least for 2 successive years.
Lerman: The critical question is "Does the application from the earlier version run on the current version?" Each time you carry another generation forward, another step forward, and try to keep upwards compatibility, you bring along additional baggage. And eventually it's a reasonable decision just to scrap it all together. But there are different models. For example, there was an operating system called MULTICS which was developed here at MIT, which is no longer commercially successful. They had a compatibility requirement. You could take the earliest MULTICS programs ever written and run them on the latest MULTICS release and they would run. They had designed in that upwards compatibility. And people would routinely take stuff that was ten years old without recompiling and run these on the system.
Hopper: That's what's needed, but how?
Lerman: It was well designed to begin with, and that helps. Everything was well defined. It was a huge project. A second issue is, of course, how much baggage you're willing to bring forward each step. I think at some point you're carrying around so much baggage you might as well just break away. We don't know where that's going to be.
Hopper: That's a key question into how well the use of Athena as a sample for the future will hold up. There's no real answer. It's according to how things go, whether or not there will be new generations, and the new generations could be completely different if you make a break. But as long as you keep compatibility, there's bound to be some similarities in the processes.
Lerman: Another interesting study is the X-Windows System. We finished version 10 at MIT. We built several X applications on it. We ultimately went to version 11 which broke version 10 applications. We went to release version 11 and installed it. Applications that required version 10 would no longer work under version 11. We made that decision consciously. Version 10 had a number of design flaws which would have made it impossible for us to promulgate it into an international standard. In order to get standardization and acceptance in the commercial market-place, we needed to change from version 10 to 11. There's an intermediate ground, which we did some of. We provided translators and compatibility switches so for about a year Athena workstations could be rebooted in version 10 mode. If you had a version 10 application, you could issue a command to turn your workstation back a generation. You could run the application, and then you could roll it forward. We also built a protocol translator.
It never worked perfectly, but there are a substantial number of version 10 applications that run on version 11. In fact that's a third major approach to upwards compatibility that I know has been used by some people at Carnegie Mellon University. The example is a language called cT (Bruce Sherwood). When cT shifts a version, all cT files are labeled as to which version they were created under, and the new version knows how to take the old files, read them, translate them into the new version, and then convert. So they provide a natural upgrade path. The end user actually gets upgraded as their versions change almost invisibly.
Passage 2
Lerman: Well there are several areas where we decided we didn't have capability. One of those things we didn't do with AthenaMuse 1 is we didn't think what it would mean to make it adaptable. In AthenaMuse 2, we're much more aware for example, one of the issues is things like color palettes. What is a computer's color palette? What is AthenaMuse's capability to adapt to different workstations' display sizes, physical dimensions, and resolutions? Ideally, applications written in AthenaMuse should be able to adjust to that. AthenaMuse should know how to remanage the real estate on the screen for a different application.
Hopper: For new capabilities that haven't been conceived of. Let's say an entirely new digital form came through, a new MIDI form, or something like that, how easy will it be to add? Are you going to need new additions, or will the expandability allow that?
Lerman: We hope to design modules, but of course the proof is will it eventually work? when new technologies come along, are they easy to integrate or hard to integrate? There's some ideas, for example, in Apple's Quick Time. They designed the compression-decompression in a place that allows you plug in new compression routines relatively easily. It's a designed in effect, a place to put in a decompression algorithm. That sort of extendibility is what we hope to design in. Will we be able to foresee all conceivable? Probably not is the bottom line.
Passage 3
Hopper: So are you aiming for a seamless environment where you don't need any programming at all?
Lerman: In terms of the description of what things look like, yes. In terms of behavior, AthenaMuse is like a very general application. You can do a lot of different things with AthenaMuse. It doesn't impose a look and feel. It allows you to describe very complicated behavior. That sort of description will probably in the foreseeable future require writing code or scripts. So there will always be some point at which, we believe, you won't have a graphical way of expressing what you want. So you will have to go in and actually write something.
Passage 4
Hopper: How would you characterize the successful efforts?
Lerman: Well, they tend to have someone who's primarily interested in the implementation and someone who's interested in the pedagogy, and they often are different people.
Hopper: Are there overlap in them?
Lerman: Somewhat. Certainly they work together. But the best results seem to be when we find someone from our staff here who understands how to build applications with someone in foreign languages, or in mechanical engineering, or neuroanatomy, or some other area, that understands what they are trying to accomplish, what they are trying to do educationally.
Hopper: Is there some need for overlap in that? Is anybody from that area going to work, or is there some characteristics of the people in the discipline that can work with AthenaMuse? Or could it be anybody who's interested in it?
Lerman: They have to be interested in it, and they have to think through what it is multimedia can do, what they want to present, and how they want to present it. They have to have some sense of vision. They also have to have at least some sense of both the strengths and weaknesses of technology. What's feasible and what's not feasible. What's going to work and what's not.
© Mary E. Hopper [MEHopper] |
MEHopper@TheWorld.com
[posted 01/01/01 | revised 02/02/02]