[vos-d] parameterized views

[Ken Taylor]

I'm not sure there's going to be one all-inclusive solution to the problem
space you describe below (though, some sub-spaces may be generalizable, for
sure). For example, one major split is the fact that for some parameterized
views, it makes sense to evaluate it server-side (or, the side that "owns"
the vobject), and for some it makes sense to evaluate it client-side (the
side retrieving a remote vobject). Looped animation, for example, should
probably be evaluated client-side rather than having the server have to send
out node/vertex movements every clock tick.

And client-side evaluation is going to need well-defined standards so that
all clients can render the result appropriatetly (though some of this can be
covered by 3rd party plugins, if the functionality falls outside of the
scope of the core protocol).

Server-side evaluation, however, doesn't *technically* need to be
standardized. The vobjects presented by the server can just transparently
contain the correct data, without the client ever needing to know whether
the back-end was some script, something like CGI, or just customized server
software.

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.

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

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.

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

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.

Hopefully some of my rambling is useful to you!

-Ken

----- Original Message ----- 
From: "Peter Amstutz" <tetron at interreality.org>
To: <vos-d at interreality.org>
Sent: Saturday, December 02, 2006 4:08 PM
Subject: [vos-d] parameterized views


> I've been thinking about the time issue a bit more, and it occurred to
> me that while time has its own quirks, the more general issue I'm trying
> to address in VOS is that of parameterized views.
>
> What I mean is, a vobject represents some logical entity.  However, how
> that entity is presented/viewed may depend on various factors -- the
> preferences and permissions of the user, the time, and also transient
> paramters like a search query.
>
> To add another motivation example, consider hypervos, which stores HTML
> in vobject structures and serves it to web clients.  Dynamic content in
> the current model is very difficult, because there is basically one
> unchanging page that everyone looks at.  You can't customize the page
> someone sees.
>
> With some notion of a "view" or context (session?) parameters, the VOS
> structure used to generate the page could be affected by these
> parameters.
>
> I'm still not sure how this will work.  The two possible strategies I've
> considered so far are a) to have some intrinsic "parameters context"
> which is used by vobjects to decide what results to give back or b) to
> establish some way of working with the vobject structure so that a
> particular view is a vobject tree in which the parameterized parts have
> been altered.
>
> For example, take area of interest management.  A user is in a sector,
> and only wants to know about avatars that are within 10m of their
> position.
>
> In case (a), when the user asks the sector vobject for its contents, the
> sector looks at the paramters (users position, and 10m radius), filters
> the avatar list and reports it back.
>
> In case (b), the user has their own private, discrete sector vobject.
> The sector vobject is connected to the "real" sector and updates its own
> child list when avatars come and go from the area of interest.  The user
> can query the avatar list directly.
>
> Each approach has advantages and disadvanges, so I'm still thinking it
> over.
>
> Comments?