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

On Tue, Jan 27, 2004 at 11:16:18PM -0500, Stefan Seefeld wrote:
> If the scene graph is to be confined to the display server, how
> is the application going to access it ? It surely needs some way
> to tell the display server what kind of scene it wants as a view
> of its data. Not having access to the SG directly, does this mean
> the new API would be less flexible, more coarse grained ?

I don't see why, in particular.  The client currently de facto doesn't
have access to the SG directly; client-side graphics have never really
worked (outside of propaganda and a few klugy experiments); we're just
make this de jure as well.

Of course, this doesn't say anything about what sort of API would be
_best_, and it makes sense to revisit things; the old system forced a
lot of API design choices on us.

[...]
> I believe our API to assemble the scene graph by means of
> kits from within the application is quite a good tool for
> UI designers. The problem is that the CORBA architecture enforces
> full location transparency, i.e. no matter whether you look at
> the objects ('Graphic') in the server or the application, you
> always see the same interface, which includes methods for
> modifying the SG topology, as well as methods to traverse
> (draw, pick) it.

Yes, exactly.

> What if the only part the application would have access to was
> the SG construction API (access child and parent graphics), and
> leave the rest (traverse, draw, pick, request) in the server ?
> (yes, DrawingKits would disappear, too, from the public interfaces)

That's how I imagine things working.

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

(Of course, this doesn't matter if we stick with CORBA and its
null security, or switch to some other ACL-or-whatever based security
model -- though the latter will require some other sort of mechanism
to deal with this sort of thing.  I suppose the meta-message here is
that discussing an API without knowing the object model in use is
problematic.)

> Suppose you hold a proxy to a graphic in the application. This
> proxy allows you to iterate over child graphics (inclusively to
> remove them), and add new graphics.
> However, these operations are all forwarded to the server, where
> the graphic implementations connect to each other *without*
> using proxy firewalls between each other.

Yeah.

> Doing this, we could set easily set up a single 'scene graph rwlock'
> that ensures no changes are made to the entire SG while any
> traversal is in progress. The application then would call methods
> to add / remove graphics, which would block (write lock) until the
> traversal is over, and then do their work.

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.

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

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

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

> I'v asked on the omniORB list, as I remember Duncan talk about custom
> proxy factories some time ago. I'm not suggesting we have to stick
> with CORBA, just that I don't feel it is a good idea to change all
> parameters at once, if we can try to understand the impact individual
> changes will have.

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.

-- Nathaniel

-- 
The Universe may  /  Be as large as they say
But it wouldn't be missed  /  If it didn't exist.
  -- Piet Hein