Some more Berlin info

[Erik Walthinsen <omega@aracnet.com>]

------- Forwarded Message
Date: Wed, 20 Aug 1997 09:57:02 +1000 (EST)
From: Nathan J Hurst <njh@cs.monash.edu.au>
To: berlin@prilnari.com
Subject: Berlin 'core' (was: Objective C- Which parts?)

Ok, now some facts are coming out!  I expect part of the reason you have 
so many people bickering over these sort of issues is because your web 
pages don't actually describe what the berlin project is, apart from near 
useless 'API's and various 'opinions' and X-bashing(indeed a friend of 
mine, who is less than an expert, said after looking at the page that it 
seemed that the project was just X-windows bashing.

Perhaps if you put this soapbox on your web page you will clarify a lot 
of things.

On Tue, 19 Aug 1997, Matt Messier wrote:

> <SOAPBOX>
> 
> So, what exactly do you believe to be the ground work for Berlin?
Ok, firstly, you web page leads me to think that you plan on using 
/dev/graphics for what you are now refering to as the core.  i.e. GGI 
will provide all the low level facilities on which berlin will be built.

If this is the case then why not just put the other functionality in GGI 
and usr other various libraries for the messaging?  GGI has been (AFAIK) 
heavily criticised by various people,including Linus Torvalds and at 
least two of the computer science Phd students here.

I believed the ground work for berlin would consist of something like 
Quickdraw, the X-window manager, a multi-queue event handler a la BeOS 
and perhaps(it doesn't really belong in berlin) input drivers.

These will all be easier to use if you don't reinvent the wheel again and 
just use a std. OO basis.  BeOS does these to an excellent extent, and 
believe me when I say that development is fun under that OS.  MacOS 
'fakes' object orientation and ends up having a very strange interface 
where objects have different behaviour in different 'managers'.

> So far,
> I have seen almost no discussion or understanding whatsoever for what the
> 'ground work' of Berlin is.  Although I've basically just thrown it in your
> face that I don't think you really know the answer to my question, I'd like
> to hear your answer anyway.
That's perhaps because you haven't said what berlin really aims to do. 
There are various wishy washy remakrs about berlin, warsaw and moscow 
being built on top of each other, then being built on GGI, but until this 
mail, there was no way for people outside your dev team to make rational 
debate.

> Don't take this the wrong way, but you're making gross accusations without
> any 'ground work' of your own.  Everybody on this list is absolutely
> obsessed with implementing widget sets.  Is THAT what the ground work for
> Berlin is?  If you think so, I'm glad you're not writing code for Berlin
> because you have a gross misunderstand of what makes a GUI work.
generalisations... from what I've seen the berlin project is taking the 
'open' approach of Apple, Sun and Microsoft.  You throw around a few buzz 
words and then leave everyone in the dark.  You might argue that people 
should join the berlindev mailing list, but if that is for dev. then it 
seems fair that this list should be for architecture, which is what is 
being discussed.

If you want this project to be successful, then put 'work done' up for 
perusing.  Document the exact architecture you want(down to the type of 
data structure intended for each step).  when people make changes, change 
the web page.

> I suppose you could say that I am the chief architect for Berlin, so you'll
> get it right from the horse's mouth.  This message is probably going to come
> across to some people as sounding arrogant and seem to be a real turn-off,
> and to that I can only say that I'm defending my turf.  I'm really a nice
> guy, and I'm open to suggestions, but let's be intelligent about this.
What experience do you have then?  Have you written a graphics subsystem 
before?  Have you written a driver for any hardware?  Reverse engineered 
a mouse controller?  Headed a 100 programmer team?  Written a popular 
product?  How many different UIMSs have you programmed sucessfully?

I'm saying any of these as requirements, but it plausible that some of 
these might give your 'high and mighty' word some weight.  Where facts 
are hiding, rumours abound.

> Ok, so now I'll answer the million dollar question.  What is the 'ground work'
> for Berlin?  It is what I refer to as the 'core' of Berlin.  It is not how
> widget sets are implemented.  It is not how things look on the screen.  It
> is not how a control reacts to a mouse button click.  It is how Berlin
> applications peacefully co-exist with each other and providing a uniform and
> well structured environment for them to run in.
Yes, exactly.

> The core of Berlin consists of a server and a client development library.
> There exists only one server, and it carries with it four basic
> responsibilities.  They are:
> 
>     1. Create an environment for clients to execute in.  This means
>        initializing the Berlin device drivers, creating communications
>        services for clients to communicate with the server with, and
>        initializing global data structures that are shared among every
>        client and the server.  For example, information about what
>        windows exist is stored in shared memory.
Ok:
  1. What level do the drivers operate?  Can existing and tested kernel 
level drivers be used?  If not, why not write them as a separate 
project?  some people might not want berlin on their machines(don't 
flame: I currently don't have X installed on our LAN server), but do want 
a <insert input/output device> driver somewhere else.

  2. Why can't existing linux message passing be used?

This stuff will be a pain if it in not OO.

>     2. Provide a context for Berlin device drivers to execute within.
>        There are two types of Berlin device drivers: input and output.
>        An example of an input device would be a keyboard or a mouse.
>        The input driver is responsible for taking input from the device
>        and generating a Berlin event to be dispatched and handled by some
>        higher level piece of code (such as a pushbutton.)
See above.

>     3. Maintain integrity of global data structures and perform garbage
>        collection.  Resources that are stored in global space (such as
>        the data structure which represents a window) must be centrally
>        maintained to some degree.  Specifically, if a client dies without
>        cleaning up resources that it has allocated, the server will do so
>        for it.  It could be said that only bad clients don't clean up
>        after themselves.  While this is partially true, what happens if
>        stupid joe user sends a SIGKILL to a client.  The client can't do
>        anything about it.  But the server can!
Yes, this would be assumed.  Presumably the only way a client can modify 
things is by calling various functions.  Each process can tag a 'data' as 
its, and garbage collection can be performed at various points, including 
when a client server 'pipe' breaks.

>     4. Provide a messaging service for device drivers, clients, and the
>        server to exchange information.  Input device drivers reside only
>        within the context of the server.  When they generate an event,
>        there has to be a means by which the event gets to the client that
>        should see it.  
So why can't you just put this in std. kernel drivers?  That would be 
something which would be fairly easy to do, and if well implemented would 
be taken on by others in the linux community for their own devices.

 > Likewise, if a client for some reason needs to send
>        a message of some kind to another client, it can do so by routing
>        the message through the server.  
What messages in particular? 

> While this would seem inefficient,
>        you're right, but it should not be a common occurence.  The other
>        solution is even less efficient -- clients communicating with each
>        other directly.  If you want a detailed explanation of why, ask me
>        and I'll tell you.
O(N) vs. O(N^2)?

> The Berlin development library provides a generic, fast, and minimal
> interface to the services that the server provides.  It provides a means
> by which windows can be created, messages sent to the server and other
> clients, and an interface to output device drivers which ultimately
> execute within the context of the program using their services.
This seems to be: write a program which maintains various regions on screen.

So, do you have a working Region data structure?  This is the basis of a 
good window manager: if you can clip every primative to this region, then 
you have basically finished the window manager.

> What everyone on this list seems to be so obsessed with and is considering
> to be the be all and end all of Berlin is what language levels of
> abstraction much higher than the true core of Berlin will be implemented
> in.  This is EXACTLY why we're developing Berlin.
No, I was debating the fundamental, underlying language architecture.  If 
Berlin were written in prolog, it would have a tendency towards 
constraint based logic, if it were written in SQL, then it would lean 
toward databases, if it were written in fortran it would lean toward 
numerical computing.

The language used directly affects the style of the resulting system(I'm 
refering to programmer's interface, not Graphical User Interface, and 
have been at all times).

> The problem is, and you'll see it all over the place, that everybody is
> concerned primarily with how a GUI looks and feels.  While this is an
> important part of a GUI, it is certainly not the be all and end all. 
I have never even considered this as part of the discussion.

> The
> Xwindows references on the Berlin web page have apparently been completely
> misunderstood.
Perhaps there is a message here somewhere-it had better get to the server...

> The 'core' of Xwindows is what is flawed.  But only in terms of a GUI.
That's strange, you web page seems to pick on, e.g. XFrameRect vs. 
XFillRect, are these flaws that will only affect GUI writters?

> Xwindows is NOT a GUI.  Xwindows implements a drawing protocol.  
yes.

> Over the
> years people have tried to force it into something that it is not, and as
> a result, it does not perform optimally.  
No, they have tried to implement(=force) various comittee designed 
toolkits over the top.

> If you compare Xwindows with 
> Windows NT, you're comparing apples and oranges.  Believe it or not, the
> 'New Technology' in Windows actually performs quite well, and was well
> thought out.  There are some flaws (most notably the horrible Win32 API),
> but the underlying architectural design is good.  Xwindows, on the other
> hand, is the product of patch on top of patch on top of patch to give
> functionality to people that was never intended to be part of X.
So X was not designed for ready extension, here we go again...

> Berlin is starting out as something quite different from Xwindows.  Yep,
> you guessed it, we're following the lead of Microsoft and Apple.  We're
> creating a GUI!  We've looked at these other GUIs and determined what
> their strengths and weaknesses are.  Our goal is to build on their
> strengths and overcome their weaknesses.  Unfortunately, my view of what
> is ultimately important an a GUI doesn't seem to mesh with the majority
> of the people involved in this discussion on this list.
Therein lies your problem: following the lead of Apple(followed by 
Microsoft), the Apple MacOS is based on Pascal and 68K Asm and was 
evolved slowly.  You want a neat solution, look at NeWS, NeXT, 
Archemedies RISC OS, BeOS.

> Look, if the true 'core' of Berlin (which is what I briefly described
> above) is flawed, what you're all discussing will have absolutely no
> relevance.  
Not at all.

> But none of you are giving any consideration to what lies
> beneath your discussions and are telling us [the Berlin Consortium]
> that what we're doing is a big mistake.  Now I'm open to that sort of
> commentary, BUT ONLY if it is a well supported accusation.  So far I've
> seen nothing other than a total lack of understanding.
from both sides.

> </SOAPBOX>

njh


------- End of Forwarded Message


        Erik Walthinsen - Programmer, webmaster, 3D artist, etc.   __
  __                                                              / /\
 /  \           omega@sequent.com         Work: (503)578-5314    / /  \
|    | M E G A  omega@aracnet.com         Home: (503)281-4281   / / /\ \
_\  /_          psu12113@odin.cc.pdx.edu  Majoring in CS       / / /\ \ \
                                                              / /_/__\ \ \
Omega Station: http://www.aracnet.com/~omega/                /________\ \ \
     Info on Linux, Graphics, Descent, Laptops, etc.         \___________\/


===
SEUL-Leaders list, seul-leaders-request@seul.org
===