[vos-d] parameterized views

[Peter Amstutz]

On Mon, Dec 04, 2006 at 01:04:13AM -0800, Ken Taylor wrote:

> Of course, it would be nice to have some standard methods already worked
> out, rather than having every server-operator fend for themselves. And also,
> omnivos needs a nice way of handling these situations. Finally, since VOS
> has the built-in ability for "clients" to modify objects, there is the
> question: what happens when a client wants to modify an object that was
> dynamically generated? So maybe this does all need to be standardized into
> the vobject model somehow.

Yes, that's the goal of all of this.  I'm not expecting the 
*implementation* to be standardized (in the sense that animation, 
revision control, area of interest management etc are all going work 
entirely differently on the backend) but I hope that the interface 
concept can be unified and incorporated into the core model.

Another related case for context-sensitivity comes to mind -- security.  
A while back Lalo and I hashed out some ideas for a capabilities-based 
security model, whereby each vobject had a "capability context" that 
defined what it was allowed to access.  Security restrictions are, after 
all, another way of controlling what a vobject is able to see.

> Another split I observe might be called "stateless" or "stateful" views. Or
> maybe "global" and "instanced" views. The idea is that stateful/instanced
> views need to store extra data for each possible value of one or more
> parameters. For instance, each user may have their own unique "view" of some
> object, which keeps track of its state relative to each user (at the
> extreme, each user or group of users could have a completely unique instance
> d view of the whole virutal world on one server, including all child
> objects). The stateless/global views, on the other hand, while they change
> according to parameters and are not static, can calculate the values to
> return "on the fly" without needing to store extra data per parameter set. A
> clock on the wall of a virutal room, for instance, which showed current
> server time, would be parameterized, but stateless. Or, at least, any state
> it had would be shared among all users and parameter sets, and extra
> instances wouldn't need to be spawned off. I hope I'm describing this
> concept well, because I feel like I'm babbling a bit...

Actually this makes complete sense.  The stateless/stateview views 
divide is reflected in the two possible implementation strategies I 
mentioned in my earlier email.  The first "stateless" strategy, you have 
one single vobject and requests are serviced on the fly.  The second 
"stateful" strategy, you define separate helper vobjects which maintain 
state reflecting the filtered/fully evaluated view of the "master" 
vobject.

> Revision control would be an example of an instanced view that's instanced
> according to the parameter of version-to-look-at. Animation has a different
> instance for each frame-to-display. But these examples don't really have the
> same intuition of "state" and "instancing" as the examples in the previous
> paragraph. This makes me uneasy, and I wonder if conceptually I'm not quite
> thinking about this straight. Maybe the difference is that animations and
> revision control histories are based on quasi-static data sets (the data
> sets can be changed, but they're changed explicitly), whereas the "world
> instancing" problem creates new data sets on-the-fly as they're accessed
> from new parameter contexts.

Well, animation involves interpolation, so you're still creating a 
transient derived data set from the source set.  Having the source set 
changing on the fly does create some interesting complications in of how 
to send out updates.

Also, one source of ideas are database views, where one table is defined 
as the results of a "SELECT ..." statement against another table.

> Not to mention that you could have user-instances of revision-controlled
> animations with LOD parameters and texture maps that change according to the
> time of day, how far away from the object you are, and your personal user
> preferences :P

And that's entirely reasonable, so we need to design for just such a 
pathalogical case :-)

> Part of me wants to say "just cover all the above with a general-purpose
> scripting interface and let the developers worry about it." But on the other
> hand, something in my intution says there *has* to be a clean, robust way of
> packaging up all the above concepts.

We already have a general purpose scripting interface in terms of being 
to bind method calls to scripts (at least, once Lalo implements it, but 
let's assume this functionality will be available).  What I'm thinking 
of is a way of communicating a calling context/parameters that's 
separate from the actual method parameters and not necessarily under the 
direct control of the caller.

> Hopefully some of my rambling is useful to you!

Very useful, actually, I think you've got a very good grasp of the 
issues and this discussion is helpful in identifying what the key issues 
really are.

[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.interreality.org/pipermail/vos-d/attachments/20061204/f241a5ec/attachment.pgp