Thread: [Vrspace-dev] Standalone VRS

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

	So I was making these new Portals, and have been all bummed out about Xj3D 
sucking, and it hit me how to do standalone VRS now with Contact.  By the 
way, Portals work nicely, gonna put em up at vrspace.org after a little 
more testing.  How do they work?  When you first log into a space, you 
create a Session, a Scene, and the Scene loads objects over the net into 
your client.  I created a new command gate:
	( syntax: /gate host port entryURL, e.g. /gate www.vrspace.org 8500 
http://www.vrspace.org/vrspace/vrspace.html )
           ( to gate within the same host: /gate _ 8501 )
When the gate command is received, the server connects to the new host, 
preserves your current socket, shuts down your current session, and starts 
to shuttle events back and forth between you and the new Session.  What 
happens when you gate again?  To avoid the issue of having the second 
server repeat the above process and thereby start linking multiple 
connections together, I have the middle server intercept the gate command 
and repeat the above.  In this way the first server you connect to, 
thereafter acts as a swivel point, each new connection is created through 
it.  So this made me think of the idea of the gateway, and a users private 
space.

	When you first login to a space, the server searches for your private 
space.  I mean by this, what we now call a Server instance.  This instance 
is loaded on the fly and contains its own collection of your personal 
objects: For example, the Console, with your preferences, the WorldEditor, 
and other personal user settings to be persisted across all spaces you 
visit.  Next, the server creates an initial double connection ( as above 
).  It then "gates" you into its own space you were trying to 
reach.  Essentially now your scene consists of two merged spaces.  The 
first of which only you know about, which is what the Console, WorldEditor, 
etc... are.  When you gate to another space, these objects remain, while 
the new space loads up.  They should receive some sort of Zone changed 
event.  One reaction is that you url preference will be sent to your class 
upon entrance into a new space.

            So yes, this involves changing the structure a bit to create 
the notion of a Zone.  Instead of restricting ourselves to one port - one 
server, we switch to one port - multiple zones.  The advantages are 
multifold and it is necessary for the above.  Of course, now messages will 
have to contain which Zone they are going to, which seems resource 
intensive, but we can add a UseZone command to specify where the next set 
of message should go.  Either way, I am advocating removing the port per 
space, instead have one server listen on 8500, and then each internal space 
contain a zone.  I imagine this will involve creating a new file called 
zones.xml or something, which will we be autogenerated when the server 
shuts down.  Twill also involve an extra step in logging in specifying 
which Zone you are interested in.  Etc...  By the way, I think we should 
remove the vrspace.cfg file.  It seems most of these settings can be stored 
in a Zone object in the Zones db, the other ones can go in zones.xml.

           What does this have to do with standalone VRS?  The gateway 
server usually will be the VRS server running on the same computer as your 
client.  Yes, as we have spoken of, we package the server with Jetty, et 
all, and call it a client.  Now when you start VRSpace, THE SERVER :) opens 
an IE window to your last open space, or something.  I am thinking of 
creating a little icon in the tool tray for the running server.  Now your 
personal space is actually stored on your local box.  So for example, I am 
integrating the uploader in the client now as follows.  When I hit the hud 
uploader button, it sends a message to my private space, and MY OWN SERVER 
opens up the uploader dialog.  Hence, no worries about the applet security 
sandbox.  All saving and loading from the local file system are done 
through the server.

           Yeah, so, I want to give the Server its own front end.  It will 
look like a basic 3d editor app.  DB files will be nothing more than that, 
files that can be "Opened" and an IE window pops up for you to edit it.  DB 
files can be shared.  Hell, we can let people zip up the whole 
structure.  When you want to make a space available for visiting, you 
specify that its public and should be started on the Client/Server 
start.   So I don't know how much more standalone we can get.  The only 
real loss is that Contact doesn't support all the nice graphical files 
formats that Xj3D would have.  We can have the video conferencing stuff, 
which will connect people from your local server to theres with ip address 
shared through a common space you are in, or let Alice talk locally :).  We 
can make the server send files to be viewed to Chisel, though I would love 
it if VrmlPad was accessible that way, though maybe it is...

            Of course, you can still run with the gateway server being 
remote as we now have it.  Actually, what I really think is necessary in 
the long run is having some sort of universal identity server ( probably 
housed at vrspace.org ).  This guy can give you a universal number ( like 
ICQ ) to uniquely identity you and act as an authority for verifying your 
password.  There are problems with other people having the same name as you 
when you want to gate...

            Here is a cool one, that I think we have all talked about for 
some time: My3DDesktop.  We can allow users logged into their own space, to 
drag windows icons into it.  This pops the actual icon image into the 
space, and then when clicked, the server will call the OS to start the 
program :)  Another one, we can have little text logins that pop up so we 
get the Unix terminal effect.
	
            Just to get it down on , er, paper, I am thinking of sending 
UDP messages from vrspace servers running to the main server to create 
heartbeating for who is online and what spaces they are advertising.  I was 
even thinking of integrating into that multi-messanging client Ka uses : 
Miranda.  Wouldn't it be cool to see VRSpace users online through 
it.  Perhaps this where JXTA enters the mix?

       Rob

Thread: [Vrspace-dev] Standalone VRS

vrspace-dev