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)
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
