Scott: The last time I visited http://www.berlin-consortium.org
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
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
course before? Does this new name change represent another change of
Stefan: not really. Berlin has indeed had a somewhat different goal
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
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
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
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
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
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
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
Scott: Berlin uses the LGPL. Did you consider other licenses
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
Scott: Any thoughts on free software in general, or earning a
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
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
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 ...?
Porter-Duff or !Porter-Duff?
gcc-2.95.* or gcc-3.*?
both, until gcc-3.x gets up to speed
libstdc++-v2 or libstdc++-v3?
Johnson, Gamma, Helm, or Vlissides?
all of them, any time.
Canada or USA?
UDP or TCP?
Reusing interfaces or reusing implementations?
Design or Evolution?
both, each has its place.
Serif or sans-Serif?
(neo) Fresco http://www.fresco.org
Vector Graphics Foundry http://sf.net/foundry/vectorgraphics
Bill Cheng Interview http://advogato.org/article/445.html
Bernhard Reiter/Bernhard Herzog Interview http://advogato.org/article/389.html