Re: [Vrspace-dev] Standalone VRS

[Josip A. <jo...@vr...>]

Rob Meyers wrote:
...
> 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.  

This is cool addition.
Now I must explain why Gate works as it works:)
Recursive symbolic reduction. It's about distributed AIML... i.e. host A 
gets some query that ends up as catchall (can't resolve it). Then it 
forwards the query to host B. B may find the appropriate category, but 
also may perform some substitutions and forward new query to another 
host, even A.
This may end with circular queries, A asking B and B asking A and so on. 
NeuroGrid should take care of it - each unresolved query means we 
believe less to this host and infinite loop should not happen.
This distributed circular symbolic reduction may be a cruical feature 
for AI (ever had a dream when a situation repeats untill waking?), says
IDM : Sources of Meaning
http://pages.prodigy.net/lofting/

>     When you first login to a space, the server searches for your 
...

But I see no advantages of zones. What you're saying won't let us carry 
personal stuff to other spaces, in other words the implementation effort 
is the same for both cases.
And still you can have personal space with existing code. Sure, we 
should add hosts_allow/hosts_deny and allow only localhost for personal 
space. Huh... not that sure: I wanna connect to my personal space from 
anywhere.
BTW to connect to another local server you can use PipedConnection, this 
is what I did with xj3dclient - start server, start client, connect via 
PipedConnection.

> 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.

I prefer properties file over xml file. As for db, better xml. Meaning 
we need VRObject.toXml() and fromXml().

>           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.

Right. Again, we don't need zones for this.
There's some ugly implications on source tree. Seems we should remove 
parser/ and move all this to main/ - I have this situation with html 
parser classes already... ?

>           Yeah, so, I want to give the Server its own front end.  It 

Right. Though I'm not that sure for it look... i.e. on startup I'd show 
some form allowing user to edit server properties.
As for runtime looks... look maybe we could use xj3d for this after all, 
and display spheres instead of users and boxes instead of objects... big 
deal with vrspace is that it's somewhat self-documenting system: each 
object has an url...

> real loss is that Contact doesn't support all the nice graphical files 

Not exactly... Contact is not compliant: script node, externproto... badbad.

> 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 :).  

Right, done some coding toward this already.

> 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...

Yeah, we should use some factory depending on mime type... i.e. i'd like 
to open() java filez with jedit, etc.

>            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...

Not exactly, Gate gives remote username <you>@<yourhost>.
As for 'universal' ID - won't work. With star structure you mention, 
we'll bring down entire network when we upgrade vrspace.org. GUID and 
stuff are somewhat better, but then we become ICANN:) Not quite p2p. 
Etc, that's why I came up with <you>@<yourhost>. Sure, it's not quite 
unique, but since <yourhost> isn't FQDN but any string, should be better.

>            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 

Right, cool.

>            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?

Here's how it works with JXTA: each server joins VRSpace peer group and 
advertizes it's services/spaces. Fetch jxta shell at jxta.org, see what 
you can do with it, source is also rather straightforward.
Then let's discuss this further. Forget UDP, JXTA is the way to go.

Regards...