Lee wrote:
>
> > > Note also that, in the context of LibGWT, I also wanted to figure out how
> > > it would be possible to share a "wisual" between various processes
> > > (top-level manager/server and child processes). I'd be interested to look
> > > on how you handle such problem within Berlin.
> >
> > I don't understand your question. berlin doesn't use libgwt. We have our
> > own region management, based on the concept of a 'scene graph', and a deferred
> > drawing model, based on scene graph traversals.
>
> Correct me if I'm off here.
>
> I believe he is talking about the CORBA. CORBA is a
> intraprocess/interprocess/internet protocol. You could have one server
> process in charge of the visual while client processes make drawing requests
> via CORBA.
some nitpicking: CORBA is *not* a communication protocol. It's an architecture
supporting 'location transparency'. The difference is significant. Lots of people
misunderstand that. They see that CORBA requests are heavy compared to simple
socket based ones (such as X), and conclude that CORBA is bloated and slow, which
it isn't.
Location transparent means that you always communicate with 'servant' objects
by means of 'proxy' objects. They implement the exact strategy needed to contact
the servant. In case of colocated objects this is a simple indirection, only if
the objects are indeed living in different address spaces, a communication protocol
such as IIOP (which is the protocol you talked about) is used. However, all this
is totally hidden from the application writer.
Nevertheless, it is clear that for efficiency it would be best to colocate the
objects which communicate most with each other. For berlin, this means that
all the scene graph nodes live in the server, the client's job is to remotely
build and adjust this scene graph to reflect the UI the client wants. The client
itself then mostly cares for the application logic.
Practically speaking, that means that 'drawing requests' in berlin remain completely
inside the server, as does all the event dispatching logic. The server only calls
back into the client if there is any change to the application's state. This has
indeed big advantages compared to X:
* massive reduction of bandwidth
* separation of UI and model domain
* centralized configuration of UI related stuff (look & feel)
Regards, Stefan
_______________________________________________________
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: [EMAIL PROTECTED]
_______________________________________________________
...ich hab' noch einen Koffer in Berlin...
