Re: [Fresco-devel] OSG-Prototype

Friedemann Gerold wrote:

> 2nd, if the client passes server-objects to some other server-object we 
> should avoid to pass corba-references. so my idea was to pass unique id's.
> 
> this means:
> 
> button.setChild(text.id());
> window.setChild(button.id());
> desktop.addChild(window.id());
> 
> on server-side we resolve this id's to pointers to the Impl-objects.
> then we can use internal interfaces directly without passing all thing
> over CORBA.

while this is indeed the idea behind the efford to encapsulate the scene-graph
inside the server, I don't see how passing an id is any better than passing
an object reference (in fact, where is the difference ?).
Passing objects allows for some type-system to kick in directly at the
communication layer, so the server backend doesn't need to care.
Beside that, I agree: what should be passed around should be much more
decoupled from the scene-graph objects (the 'servants' as they are called
in CORBA slang).

> what level of scenegraph the client should manipulate? in my draft i 
> build my own tree of hight-level objects the client can manipulate. is 
> this ok?

I believe the client should be able to construct and manipulate the scene graph
(well, a subgraph he is authorized to access). This really boils down to methods
such as 'begin()' and 'end()' for child iteration, and 'insert()', 'remove()' for
tree manipulation.

Another point you address (and which we touched on in the last IRC) is the
separation between graphic node and GUI model. I think everything agrees that
the application logic is kept inside the clients, but what about the GUI models ?
Who maintains the widget state ? (and, assuming the answer is 'the server':
how rich should these models become ? In the 'old' fresco API they were really
minimalist, but people complained that this API was arcane and non-intuitive).

Regards,
		Stefan