Actions as transactions

The more I think Scene Actions, the more it gnaws at me that we are in 
some way talking about a specialized database application. I don't know 
databases, however, so this is very much just a feeling. But it 
certainly seems as though there's a lot of searching, sorting, and 
selecting being done by the Scene Actions. And the threat of 
multi-threaded or multi-client access is also very database-like. So I 
thought I should bring it up, as a means of understanding the process 
distinct from the part about painting pixels.

If a scene were to be treated like a database, what sort of assumptions 
would the nature of the data allow us to make that would simplify the 
design of the (programming) interface?

The data is all linked together in a hierarchy
There are only a few kinds of data (groups, shapes, geometry, lights, 
attributes/appearance)
Very large quantities of structured data are regularly requested -- to 
be rendered
Certain data might be read-only (static and compiled data)

I'm intrigued by the RenderMan RIB as the solution model for 
transferring large rendering instructions between RenderKit and the 
Renderer plug-in. If one was loose in one's definitions, it could 
almost be comparable to a database table in its ASCII form. In any case 
a serialized representation, as opposed to direct API calls, which is 
therefore data-driven (i.e.: more database-like), not code-driven. 
Therefore more versatile, and slower. Does this conceptual approach 
offer us any new insights or opportunities?

I've downloaded the RenderMan Interface spec (3.2). I can't find 
anything about NeXT 3DKit yet, so links are requested (or if you have 
docs, email/instant message me -- brentgulanowski(at)mac.com via AIM 
will work). I have quite a lot of reading to do this week.

Brent Gulanowski
--
Mac game development news and discussion
http://www.idevgames.com