[vos-d] thoughts for 0.24

[Karsten Otto]

Am 24.04.2006 um 07:06 schrieb Peter Amstutz:
> Alright, tentatively, here's what is on the menu for 0.24:
>
>  * Move to bzr for repository access.  I'm currently testing this,  
> and we are waiting for a new version of bzr before this can go live.
>
OMG, yet another revision control system... oh well, just include a  
cookbook example in the VOS manual, and I guess I can manage :-)

>  * OS X support (for real).  Adu is working on it, and also I have  
> a Mac on my desk now.  It's old and slow, but it's a start.
>
Yay! Three cheers for tetron and adu! Is this gonna be 10.2, 10.3, or  
10.4 based? They all have different build tools, like gcc versions  
etc., which might break a few things... In any case, I will continue  
to be a tester (read guinea pig/whiner) for any VOS Mac release you  
throw at me :-)

>  * Make Property be a template.  This provides various advantages.  
> First, the property class would store the "real" data type (int,  
> float) instead of writing it out to a string and having to parse it  
> every time, so it would be faster.  Second, it would eliminate the  
> ugly (ugly, ugly, ugly) getProperty/setProperty API that has  
> several dozen special cases for a variety of data types.  Third, it  
> would enforce the currently-ignored datatypes on properties.   
> Fourth, it would allow for selecting different transport encodings,  
> such as either a text encoding or a binary encoding.
>
Great, I remember I did not like the old handling even back in S3. I  
assume the string transport would be compatible with VOP, and the  
binary encoding something like the binary VIP message encoding?

>  * New connection system, based on public key fingerprints.  This  
> is still in the design stages, but it is important as it will be a  
> fairly low-level change to VOS that will solve a lot of problems  
> and add important new capabilities in terms of security and  
> authentication.
>
Hm... while security is usually a good thing, I am not sure if it is  
all that important right now. Consider that even without https, http  
is quite useful by its own. I believe whats more important in the  
security department is a consistent handling of avatars, which right  
now looks kinda broken to me.

On the other hand, for a quick solution, running the freshly  
reincarnated VOP/TCP over SSL sockets should not be that difficult.  
Then you get at least the same level of security as https, enabling  
secure plain passwort transmission, etc. Of course this wont work for  
VIP, which needs individual packet encryption/signing/replay- 
prevention/... So in general, vops will be easier to achieve than  
vips :-)

>  * X3D interchange profile support (requires object hierachies in  
> A3DL) Discussed a bit in my previous email.  There is a relatively  
> lightweight subset of VRML/X3D that is mainly concerned with  
> geometry and texturing. I want to support seamlessly loading that.
>
>  * Python.  Basically spend a few weeks seeing if the Python  
> bindings can be brought up to speed, and write an omnivos module  
> that allows running python scripts stored in properties.
>
Sounds nice.

>  * misc:clickable - very basic interaction hook, would indicate  
> clicking on an object should send a "clicked" message.  Would allow  
> for simple world interaction, when paired with python scripts.
>
I do not quite understand this. I assume the "clicked" message will  
be generated by the browser and sent to the clickable object, so it  
can react in some way? In this case, I would like to propose a small  
extension: Add two optional fields to the message, the first  
indicating an interaction mode/keyword (defaulting to "use"), the  
second another vobject. This way you wind up with the same power of  
interaction as your average point+click adventure game:

keyword		target vobject	extra vobject
USE		door
UNLOCK	door		WITH key
KICK		door
SHOOT		door		WITH rocket-launcher

and so on. Interpretation of these is of course up to the target  
vobject, which may be a python script, or have some hard coded  
behaviour (C++). The target vobject might also
support a simple message to query its supported keywords, for a pop- 
up menu or something.

The extra fields of the message can be preset in the browser(- 
vobject) and just get sent along when a click is detected (pick-ray  
or whatever). The presets could be changed by GUI elements. IMHO,  
this small extension is not much more work, but pretty powerful.

>  * Layers in A3DL - a new rendering model for A3DL.  Have a client- 
> side vobject representing the actual browser view.  This has a list  
> of layers, which are rendered in order, possibly clearing the z- 
> buffer between each layer.  A typical example would be a 3 layered  
> scene, with three layers: the skybox, the actual shared scene, and  
> a HUD or overlay GUI which is specific to the user.  Each layer is  
> rendered on top of the next and with a separate view.
>
Sounds good. I assume a "layer" is a list of one or more sectors to  
render? You would have the local GUI sector topmost, one or more  
world sectors (=zones) in the middle, and the current worlds' skybox  
in the back? Also, if you do not only reset the z-buffer but clip- 
ranges too, thins might be useful for implementing simple portals...

> Other stuff: fix irc bridge, make ter'angreal ask you for a name  
> when you use it, improve the UI, change the A3DL coordinate system  
> (!), redo the web page, incorporate adu's new logo, make sure VOS  
> works over slow modems, work on our marketing to developers...
>
>
> - -> Discussion:  Am I leaving anything out?  At the current pace  
> this is easily six months of work and probably more, so if possible  
> we don't want to add any tasks and if possible it might be  
> preferable to break things up more and do 1 feature = 1 release  
> (although development of different things tends to be interleaved  
> which makes that difficult).

Let me add my notion of multi-sector support to the wishlist, as  
discussed on IRC last night. The idea is that terangreal should be  
able to access and render mutliple world sectors at once. In addition  
with portal links, this enables a simple zone-based area of interest  
management, with zone=world-sector. Note that portal links may  
initially be as simple as "place the origin of that other world at  
these coordinates relative to this world", and adding view  
restricting geometry in a later release. Again, I think this will not  
be too difficult to implement, and tie in nicely with the rendering  
layer concept (see above).

Now, if I only had time to work on some of these wishlist items...

Regards,
Karsten Otto (kao)