Subject: [vwrap] realXtend is interested in implementing, and human friendly URNs

From: Toni Alatalo <[email-masked]>
Date: Sat, 26 Mar 2011 23:31:17 +0200

Hi,

I'm sorry for not participating here earlier. Just a quick note to say
that we are interested in implementing good VW standards in the
realXtend project -- the long term goal of the project is
standardization, like the frontpage says right at start: "realXtend
speeds up the development of the global standardized 3D internet of
virtual worlds".

Our strategy for it has been to implement quickly what we need, so
haven't had much time for talks (the Finnish style :) But using existing
standards such as HTTP, ECMAScript (Javascript), XMPP, COLLADA etc., via
existing open source libs (qt, telepathy, openassetimport, ..)

So if there are people here who can work on specs etc., we're happy to
work both on prototyping and adopting the already existing
implementations, which are already in production use, to use the
standards. We can also give commit rights for developers from anywhere.

Our very basics are put together now, the Tundra SDK is close to being
frozen for 1.0, so can now take a breath a bit and look into standards
and interop more. The requirements from our part are somewhat clear,
'cause the implementation and demos feature the basics of what we need.

So far we've done very little regarding recent VWRAP output, but it's
still a beginning: this handles vwrap calmj launch docs in the internal
web viewer in Naali which can be used as the login UI / startup screen,
https://github.com/realXtend/naali/blob/tundra/bin/pymodules/login/webui.py .. the plan is to use that against the simiangrid integration on the Tundra server side, which is at https://github.com/realXtend/naali/blob/tundra/bin/pymodules/simiangrid/auth.py
(currently only works for simple username+password auth against
simiangrid)

One reason why we haven't participated earlier in VWRAP is that our
focus has been on the scene functionality and application APIs. The
equivalent of the DOM in the html land basically. IIRC it was John
Hurliman who said on IRC last autumn or so that it's still out of scope
for VWRAP, that you perhaps get to it in some years? For authentication
and such we are happy to use existing things like openid/oath/something
if they are good, and I trust this group to tell what works :) One
reason why I started work on the simiangrid integration was to get
OpenID auth back to our new Tundra platform -- the Opensimulator based
Taiga had it since the beginning 'cause we implemented it to Cable Beach
(the old version of simiangrid, and a standards effort that John merged
to VWRAP).

For scene / application functionality we are proposing the
entity-component model, which is implemented in Naali/Tundra and also
for partial functionality in the ModRex module for Opensimulator.
Opensimulator would also want it for core, but it's not there yet. For
more info, there's a draft article submitted for a magazine, currently
under review:
https://github.com/realXtend/doc/blob/master/arch_article/simple.pdf?raw=true (also a html view is available, but github fails to show the images there: https://github.com/realXtend/doc/blob/master/arch_article/simple.rst . Any comments about the article are very welcome btw!

Google protobufs, or something like that, is fine for messaging. We are
currently using the knet library for networking -- it is application
independent, not VW specific, just a basic udp lib like enet, but it can
run over tcp as well. Has a message description system similar to
protobufs, but the serialization is independent of the transport so
allows using protobufs or any other serialization too. There is two
reasons for using knet currently: a) it performed better than enet
regarding flow control in our tests b) it is written by the guy (Jukka
Jylänki) who integrated it to Naali/Tundra, and the job had to be done
really quickly (in a month or so last autumn). The lib does predate reX
and wasn't originally made for VWs so is not a worst case of NIH :) Code
is at https://bitbucket.org/clb/knet/ and docs (good! better than enet
or almost any similar udp lib?) at http://clb.demon.fi/knet/

Finally a bit about URNs, as that is the reason what drove me to look
into standards now. I'd like to implement URN asset references, as a
simple way to put objects in scenes without needing to worry about
locations and to support both offline & online use etc. This is my
current draft:

xxx:std:cube.mesh #a standard 1,1,1 cube that everyone agrees on
xxx:std:teapot.mesh #come on, we could have this at least?-)
xxx:rex:white_tailed_deer.mesh #currently in
http://www.realxtend.org/world/lvm/White_Tailed_Deer/ .. but is not
really tied to this world. is currently reX's best shot at making a
white tailed deer, not necessarily what everyone agrees for standard.

The namespace idea is similar to the existing: urn:ietf:rfc:2648

I wanted to make a new little demo where can walk around as the deer, in
a different setting than the scene in that 'lvm' (Chesapeake bay,
actually) project. Could just use http refs, but would not like to break
how our little demo scenes work also offline. Eventually plan to use
content based addressing for the actual data fetching, like magnet /
something bittorrent style, which I saw had been discussed here too
extensively.

But on top of that, I'd want named refs to give two things:
1) nice human usable names
2) mutability

The idea is that if that named asset is updated, the refs should pick up
the new version. I think this is a bit similar to how inventory works in
SL (am not sure, haven't used inventories much, we don't basically use
them at all in reX anymore .. for Tundra there isn't even an
implementation, and it would be an application level thing / a script
anyway).

The question is: what should 'xxx' be?-) 

My current idea is name:std:cube.mesh but 'name' feels stupid as a URN
scheme, 'cause every URN is a name :o .. urn:file:std:mesh.cube might
kind of make sense, 'cause it is a filename in the end, but that seems
bad 'cause file: is also a URL type of course. urn:filename?

I don't think this should be VW specific.

~Toni

BTW: I've no idea whether it's better to keep this work here, or restart
somehow, but I do hope that some sort of standards and interops efforts
continue. Am still mostly interested in the 3d scene stuff, for example
I'm fairly certain that we can have JS level interoperability in e.g.
Naali, OpenWonderland and Sirikata so that api-wise simple things like
camera animation scripts can work in all. For example a decent 3rd
person camera implementation basically only needs raycasting or some
other way to get occlusion info from the scene, and means to move and
rotate the camera. But then the camera movement logic code itself can be
very complex.