Re: [Fresco-devel] OSG-Prototype

Stefan Seefeld wrote:

> 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 ?). 

CORBA-object-ref's are untrusted. iirc here is no way to check where the 
object on the other side is
implemented without calling into such an object. a call to an 
CORBA-object is dangerous because you don't know
where you relly call in. what happens if the client instances his own 
implementation and does a big sleep(100000000000); in
it?

The Idea is to use CORBA only for the public client-interface. If we 
want to do things on the server-side internally
(for example connecting nodes), we can bypass CORBA by using nativ C++ 
method calls on this Impl-Classes.
we don't need to make the whole interface public to CORBA.

> Passing objects allows for some type-system to kick in directly at the
> communication layer, so the server backend doesn't need to care.

hm... don't get it :-/
sorry

> 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).

the client creates and collects components like windows, layouts and 
controls. and we
need something for custom drawing. this "servants" will use osg... they 
will create osg-nodes
and manipulating them on the osg-scene-graph.

>> 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.

ok

> 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).

here, the MVC come in mind... i don't know... let's find a "intiutive" 
gui-model ;-)

> Regards,
>         Stefan

many thanx!
cinap_lenrek

> _______________________________________________
> Fresco-devel mailing list
> [email protected]
> http://lists.fresco.org/cgi-bin/listinfo/fresco-devel
>
>