[Vrspace-dev] Standalone VRS
Brought to you by:
jalmasi
|
From: Rob M. <ro...@vr...> - 2004-08-17 00:05:12
|
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 |