[Fresco-devel] scene graph and location transparency

hi there,

after we had our meeting I'v been thinking about various issues
that have come up. In particular, as I believe quite a number of
them can be looked at independently, I'd like to start throwing
out some ideas that don't require to consider all the issues
at the same time.

One of the points we all seemed to agree upon was that we wanted
to push CORBA (or 'location transparency') out of the scene graph.
While some of you are already thinking about how to replace CORBA
itself, I'd like to focus for a moment on the scene graph API
and how it would be used. Such a discussion shouldn't be affected
by any decisions made on the networking protocol (CORBA or not),
especially as the questions coming up are quite high level...

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'v been thinking about a design that lets us experiment with
new approaches without getting overboard with all the details
involved in reinventing a distributed object system.

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.

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)

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

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.

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.

Comments ?

Regards,
		Stefan