[vos-d] thoughts for 0.24

[Karsten Otto]

Am 26.04.2006 um 02:49 schrieb Reed Hedges:

> [snip]
>
> Well, I was trying to make the first phases be simpler, then once we
> know needs, devise something complex. You probably have more  
> experience
> with creating complex actions like this between agents though.
>
>
> browser really means "user agent" where the user could be human or  
> not I
> guess. Or you could use the avatar object, not the browser.  What I
> meant was, you can use Vobject linking to connect the different  
> objects
> you are using together, before performing the action.  Then you can
> devise any kind of relationships between objects.  So not just <VERB>
> the <OBJECT> with the <SUBJECT>.
>
> But that's just a second idea I had, not sure yet if it's good or not.
>
Ok, o what you are suggesting is something like: loosely connect all  
the pieces involved, then cast the spell that will weld/transform  
them into something new.

The problem I see with this is access control related. The target  
vobject may not allow you to do the final welding/transforming/ 
whatever, either by policy or by application semantics. In this case  
you have to roll back the changes you made before, which is tedious.

My suggestion instead was something like: tell the target what you  
want it to do and which other vobjects are involved, and let it  
determine what to make of this request. So, either it accepts the  
request and changes the world accordingly, or it rejects it and there  
is no change at all, and nothing to roll back.

This of course requires a precise expression of what action you  
expect, hence my comment about machine-understandable action terms.

> [snip, I agree to your definition]
>
>> Basically yes, I want to see all the objects from all the sectors at
>> once. For this to work, you need spation relations between the zones
>> (=sectors), otherwise they would all wind up on top of each other.  
>> So  a
>> zone needs to specify a "link" to another zone, saying something   
>> like
>> "from my point of view, this other zone's origin lies at   
>> (100,0,-50)".
>
> I see.
>
> If you want sectors to share objects, they can just share  
> objects.   If
> you want to use several servers to host different objects within a
> sector, you just do that, but one server has the actual sector object.
>
> Trying to stick sectors together like that would just make things kind
> of complicated, for the client and for scripts, don't you think?
>

No, I don't want to stick all vobjects together in a sector; each  
sector is supposed to still hold its own vobjects (ok sharing is a  
special case).

What I *want* is only the ability to link abstract "worlds" together.  
Like, the pyramid world says that the blocks world is next to it (and  
vice versa, though thats optional imho). Then the client accessing  
the pyramid world will find this link and (assuming enough processing  
power) access the blocks world too, displaying them next to each  
other as intended.

As I said before, this does not necessary involve portals; it is just  
a matter of how you populate the local scene graph of  your browser.  
I.e., you so not place all objects directly under your browser root,  
but represent each sector with its own transform, and its children  
relative to that. The transform of the "current" sector is at the  
local origin, the other sector transforms are determined by the  
links. Voila! Pyramid next to Blocks.

But I now remember somebody saying that CrystalSpace cannot handle  
hierarchical transforms, so this may actually turn out to be too  
complex to implement after all. Doh!

>
> [snip, again agree to the definition]
>

Regards,
Karsten Otto