Hi all, it seems like I finally begin to understand what this view issue is all about... One more point for clarification please:
Are view parameters mandatory or optional? A mandatory view could be assigned to a user by the site, and thus act in a similar way as access control, i.e. restricting the way the user can see or interact with the world. The important fact here is that both site and client must understand all view parameters in their entirety for the whole thing to work, and to avoid misunderstanding. The view parameters also need a form of meta- capability, to control if or how a user may pass it to another user; after all, the other user may not be allowed to see what I see! The implementation for this requires a mandatory capability object that is implicitly passed to each method. An optional view would reflect user preferences, such as AOI parameters or versioning. The site should heed these parameters if possible, but may ignore any parameters (even all) if it does not understand them, i.e. has no built-in support (extension?) to provide the requested functionality. If a site can handle AOI but not versioning, it will provide an extract of the current world, instead of yesterdays version. Also, a user may pass his view parameters to another user without restriction. The implementation would be something like environment variables that a method may look up if it supports them. Regards, Karsten Otto (kao) Am 12.12.2006 um 06:51 schrieb Peter Amstutz: > Hi Reed, > > This is essentially the two approaches to how you might implement a > "view" that I have been considering. On the one hand, you have some > kind of server-side trickery that basically serves up different > data to > different people, so everyone just sees what they want to see. On the > other, you create lots of new vobjects that act basically as > proxies to > the "real" vobject but apply some transformation or filtering policy. > > I'm not really comfortable with using the access control system for > this, though, since security policies (or capabilities!) define > what you > *can't* see, whereas a view filters out what you *don't want* to see. > Access control is also a very blunt instrument, since you now don't > know > if an access control error is due to being genuinely locked out or > just > a transient application of "you can't see that from where you are" > policy. > > Having discrete vobjects represent proxies has the advantage of being > able to give a link to another user and then in principal they > would be > able to see exactly what you see. The disadvantage is I am now > looking > at something that is not the "real" vobject, and so something that > references the 3D sector as a whole would (applied naively) reference > your personal proxy object and not the actual 3D sector vobject that > everyone shares. (Except they don't, because they have their view > proxies). The semantics of writing back to the original vobject > "through" a proxy object also get kind of ugly. > > I think the problem we're really trying to solve, the "parameters" > in a > parameterized view, is having a context or environment that > modifies the > results of an action. As an example, I ask for the child list, and > supply a context of "I'm at location XYZ and have an area of > interest of > 10 meters" then the sector can use that context to constrain what it > returns back to me. > > What's really important, I think, is that you be able to capture a > context and send it to another user. So now you and I can refer to > the > same set of vobjects (no proxies to mess up our references) and if we > need to reconcile our views, we can share the context that was used to > create that view. Access control is still applied, but it's an > orthogonal issue. > > I think this solves Kao's issue of having as much as possible a > unified > space for semantic reasons. Also, a view should be a pretty well > defined parameter space, so it should be possible to scan or iterate > through views. Going back to the original motivation, "Time" would > be a > view parameter, so by iterating or scanning through time you can > see all > the frames or checkins over the timespan of your animation or version > control data. > > I'm not yet sure what the best implementation of this. Also, the line > between what is a contextual parameter and a plain method parameter is > somewhat fuzzy, although it's fairly obvious when the context is being > used to affect the output of an existing core function like > getChildren(). > > Thoughts? > _______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
