Advogato: Interview with Stefan Seefeld of Berlin/Fresco

Scott: The last time I visited http://www.berlin-consortium.org I got the feeling you're contemplating a name change for the project. What's the new name, and why?

Stefan: When the berlin project was founded, the name was a pun with names of related projects. However, these jokes get old, and at some point they lost all contextual meaning. Since we inherit most of the architecture and design from the former Fresco project, we decided to adopt that name. So, in a certain respect, it's not a new name, but an old one that we are getting back to.

Scott: Can you fill in some more of the history of this source code?

Stefan: In the beginning there were people such as Mark Linton, John Vlissides, and Paul Calder, who played around with Structured Graphics and Graphical User Interfaces, centered around the 'InterViews' project that was developed at Stanford University. That was in the late eighties. This project evolved, and Vlissides wrote his dissertation about a Graphical Editor Framework, 'Unidraw', founded on InterViews. At the same time, Mark Linton introduced CORBA to the project, to get distributed graphical embedding, and other novel features. By the time (in the early nineties), the project was known as 'Fresco', and was hosted by the X Consortium. At some point, probably when an attempt made by Fujitsu to standardize Fresco following a Request for Proposal by the Object Management Group failed (it was IBM and Apple who won with their OpenDoc architecture), Fresco was officially dropped. It still lived on for another couple of years, as an Open Source project, maintained by Thomas Hiller. The last release is from 1998.

At about that time I joined the Berlin project and suggested that we aggressively reuse Fresco's architecture and design. For the last three years I have been doing just that: I reimplemented ideas from Fresco in the context of Berlin, on top of low level libraries such as GGI, using a real (and independent) ORB, etc.

Scott: How about the history of the Berlin project. Hasn't it changed course before? Does this new name change represent another change of course?

Stefan: not really. Berlin has indeed had a somewhat different goal at the start. But the current name change is merely to reflect the changes we agreed upon three years ago, i.e. to leverage existing knowledge, standards, and free source code, instead of trying to redesign and reimplement everything from scratch.

Scott: It's my understanding that Berlin's innovation is the merging of a generic toolkit into the server and the exporting of that toolkit's API via CORBA. Can you comment on how that will change the experience for a programmer familiar with an object-oriented client-side framework like Qt, or InterViews? How about a programmer familiar with the server-less MFC (Microsoft Foundation Classes)?

Stefan: Yeah, there is quite some difference in the way an application creates and maintains its GUI in Fresco as opposed to conventional toolkits. For one, we try to separate application domain and presentation layer as much as we can, logically, by using the Model-View-Controller paradigm, and with respect to server-client separation, in that in Fresco the GUI is almost completely hosted in the server process. It's the server which can - by means of a highly modular and extensible structure - provide all elements needed to construct complex User Interfaces. All the client has to do is plug the parts together (remotely, via CORBA !). The actual GUI, then, is a scene graph, very similar to scenes in tools like OpenInventor. All an application programmer has to do is provide the 'models', i.e. objects that implement the application logic, and hook them up with the nodes in that scene graph, so both sides keep in sync.

Scott: Any thoughts on adding .NET (CSL/Mono/etc.) capability to Berlin?

Stefan: Well, the goal at this point is really to provide an architecture for GUI construction. We are not concerned about the application logic, just how to interface it.

Scott: Has anybody had a chance to benchmark average GUI performance of Berlin in comparison to Qt/X11 and/or Qt/Embedded on BSD or Linux?

Stefan: No, and I'm not sure that this would be very meaningful at this point. Lots of the technologies we are using are still moving targets. we still don't have much h/w acceleration, even though we can target a multitude of 'console' libraries (GGI and SDL are the most popular candidates to date). Also we are working on some specific optimizations to make CORBA calls as efficient as simple virtual methods. All this has a tremendous influence on Fresco's performance. Unfortunately, the only ORB which supports enough features to work with Fresco is omniORB, and the situation is similar for other technologies we depend on. This means that it is hard to test how scalable our architecture really is. There is a lot of work going on right now, over a couple of months we had a speed improvement of about a factor of four. At the same time people are actively working on running Fresco on a PDA. Let's see how all this turns out...

Scott: What has Berlin got going for it in terms of (scaleable) vector-graphics? Any plans for a drawing editor?

Stefan: Well, the whole GUI is a big vector based scene graph, it is fully transparent to any kind of linear transformation or other graphical settings such as color, transparency, etc. We render it by means of a 'DrawingKit', and one of the latest additions was an implementation of a DrawingKit in terms of PostScript, i.e. we can render to ps, meaning that we can print directly to a vector-based format, without going through any pixmap stage. As to a drawing editor, yes, I'm already toying with some design from John Vlissides' Work on the Unidraw framework...

Scott: I know you have some sort of an implementation of John Vlissides' Tooled Composite Compound Design Pattern (http://www.c2.com/cgi/wiki?TooledComposite) in the current Berlin. How has that worked out in the Berlin architecture?

Stefan: That is a very interesting aspect. The hard part is that we try to minimize the interfaces that have to be exposed through CORBA. Diversity is achieved by composing complex structures from simple building blocks. That is true for the scene graph which makes excessive use of the decorator and composite patterns, but it's true also for other types of objects, such as commands, tools, models. What is really hard is the fact that in a distributed environment, you can't just subclass to modify the behavior of a type. The object you want to change may live in a different address space, so you have to use decoration and composition instead, which is not always enough. One answer is to migrate some objects into the client address space, another is to provide server side modules that add the desired functionality.

Scott: Berlin uses the LGPL. Did you consider other licenses (like GPL or BSD/X11)? Is there anything about the LGPL you don't like?

Stefan: No. In fact, I didn't think very long about alternatives. One danger is still the proliferation of new licenses, which makes it hard to contribute code, or to evaluate the risk associated with the use of software covered by them.

Scott: What's your stock answer for those who ask why your "competing" with X Windows?

Stefan: at this point I wouldn't pretend I'm competing with X Windows. I fully acknowledge the importance of a reliable windowing system for which a lot of support exists.

But that doesn't mean there is no place for research and play to find ways to make things better. There are clearly questions to which X doesn't provide an answer, where the X protocol itself is very limitting. The typical points to cite are certainly the high bandwidth due to the fine-grained nature of the X protocol, as well as the proliferation of (client-side) toolkits, together with an extremely inconsistent look and feel you have to face on a typical X desktop. But again, we are not directly aiming at replacing X anytime soon. We are exploring. Homo ludens meets homo faber.

Scott: What's your programming background? When did you start? Why do you carry on? When do you get to work on free software?

Stefan: I'm trained in physics, so I have been doing lots of simulations of all sorts (stochastic systems as well as molecular dynamics), and I did my share of scientific visualization. These days I'm working on Computer Assisted Surgery, where I have a lot of fun with visualization as well as some rather specific demands for GUIs, and generally doing a lot of software architecture stuff.

I try to educate people about Free Software and its value, but the real work on Free Software projects such as Fresco I do in my spare time.

Scott: Any thoughts on free software in general, or earning a living from free software?

Stefan: Right now I'm not so much interested in writing free software for a living. Instead, I try to approach this point from the other side, educating the people I work with about the value of Free Software and the culture surrounding it. This means for example to use existing software whenever we can, instead of reinventing the wheel over and over. It means to contribute to existing projects, by bug fixing or adding features we need. People should learn that sharing knowledge is a very efficient way to get the job done.

Scott: Any question I didn't ask you wish I had?

Stefan: Fresco, Berlin, Warsaw, Prague, and all the other names you use...

Do you have a roadmap for people not to get confused ?

Scott: Ok, so what's the answer?

Stefan: When I joined, I was wondering because 'Warsaw' referred to the interface, and 'Berlin' to the implementation. I found it pretty strange that the project was named after an implementation, not the interface. Now we have a unique chance to fix that :-)

The term 'Fresco' now refers to two things: the project as a whole, as well as the interface part, i.e. the protocol and 'runtime environment' you can generate from it for all the different languages. 'Berlin' stands for the reference implementation we are building, written in C++. That's about the same relationship as X11 and XFree86. By the way, the name change will happen within the next couple of weeks, together with a new release and a total web site overhaul...

Scott: Thanks very much for your time. I don't know if you read the earlier interviews in this series, but I closed each one with a list of tailored alternates to which you can answer one, or the other, or both, or none, or huh? Have fun...

RGB or CMYK or ...?

RGB

Porter-Duff or !Porter-Duff?

Porter-Duff

gcc-2.95.* or gcc-3.*?

both, until gcc-3.x gets up to speed

libstdc++-v2 or libstdc++-v3?

libstdc++-v3

Johnson, Gamma, Helm, or Vlissides?

all of them, any time.

Canada or USA?

huh ?