Re: [Fresco-devel] scene graph and location transparency

Nathaniel Smith wrote:

> My only quibble is that I'm not sure graphic handles should allow
> access to parents; in a capability regime, unrestricted traversal is a
> serious security hole.

you are right. A given 'root' graphic would be the client's access
points, everything below would be hidden.

> It's even more complicated than this,
> actually; it should be possible to create facets that don't allow
> remote traversal at all.  This way I can hand you a reference to my
> scene graph to embed inside yours, and neither of us have to worry
> about the other maliciously mucking about with our objects.

indeed. And with a decoupled proxy<->servant model this wouldn't
even be hard from a design point of view.

> One can even do cleverer things -- e.g., make the scene graph copy on
> write, serialize modifications (probably at the level of the network
> main loop), and then the draw and pick threads get to run over a
> static snapshot of the scene graph.  This gives concurrency with
> nearly no locking.

youp, that's one thing I was thinking about. OSG does such tricks,
and I'm even wondering whether we couldn't just try out test 
implementations of the scene graph using OSG. (THe nice thing about
the non-transparency is that we have much more freedom to swap the
scene graph implementation without anybody to notice.)

> (I'm not sure if this works out all the way -- I think I can handle
> memory management okay, but I'm not sure how high copying overhead
> would be.  Using appropriate data structures for representing scene
> graph state might help a lot.)
> 
> (Again, of course, this doesn't matter if we're still using CORBA and
> have to accept that a call could come in at any time on any thread,
> and have to use paranoid locking everywhere.)

I'm not sure. I asked on the omniORB list as I remember some way
to use custom proxy implementations. Of course, that wouldn't be
CORBA any more. I'm just saying that to CORBA or not isn't necessarily
a big matter as it sounds. We could do it gradually, at least in the
prototyping phase.


>>These proxies are created on demand, i.e. if you ask a parent proxy
>>for its child, it would send a request to the SG node it is wrapping,
>>which would access the child in question, and create a child proxy
>>that is handed back to the application.
>>That sounds relatively easy to implement (based on the current code),
>>so we could get some working examples up and running fairly quickly,
>>if only to see how such a design would work out.
> 
> 
> Sure, good idea.  Doesn't this require that we be able to map from
> CORBA references to scene graph nodes, though?  How do you plan to do
> that?

see above. Using custom proxy classes that give direct access to the
servants (and thus break location transparency). Again, I'm not
suggesting that as a (final) solution. Just a cheap way to start
playing.

> (I guess the natural way is to give the proxies an attribute
> "server_id" containing a unique tag, and then keep a bit table
> in-server to map these to C++ objects.  Alternatively one could try to
> come up with tricks involving Deep Corba Magic or Really Clever
> Pointer Twiddling, but these seems Harder.)
> 
> (On the other hand, maybe that only seems the natural way to me
> because it's more-or-less using CORBA hacks to emulate some parts of
> my proposed protocol.)

As I said, I'm trying to keep out of the protocol discussion for now,
as we ought to figure out what kind of data exchange we want across the
network, and how a design would need to look like. That will provide
the requirements for a more detailed protocol spec.

> Fair enough.  I guess my only doubt is that so many aspects of the
> current design are built around CORBA's limitations that 1) we'll have
> difficulty testing out other possibilities while still using CORBA and
> 2) removing CORBA will require changing so many other things anyway
> that we don't save much by changing a few ahead of time.  But it's
> definitely worth thinking about our options.

We'll hopefully find out. :-)

Stefan