Thread: [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 |
|
From: Josip A. <jo...@vr...> - 2004-08-18 12:27:54
|
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... |
|
From: Rob M. <ro...@vr...> - 2004-08-18 23:20:52
|
At 08:20 AM 8/18/2004, you wrote: 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/ This questions concerns whether to link spaces together one after one as you visit them, or to always have two hop connection: first to your gateway, and your gateway to the current space. I have a very basic objection to linking: It is incredibly slow. I could even feel the effects on my local box after making something around six jumps. Add to that, it doesn't make sense. If I have left a space by gating to another, I have no objects from that space left in my Scene. Therefore, there is nothing for me to communicate with in that server any more. I don't fully understand, know you have explained several times, a very concrete example would be helpful. This is the way I see it. If a server needs to ask other servers with help concerning answering a query, then those servers should set up a peer group for resolving the answer. It is quite arbitrary to link servers together by the path you happened to take today. If you want, let this arbitrary path make suggestions to server as to which other server it should contact next. Either way, making multiple server move your requests around is resource wasteful, and I don't even think speed implementable. Don't get me wrong, I like the idea of servers being set up in a net where they can find solutions together, but it doesn't have to have anything to do with the client. >> 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. Ports versus Zones: I am completely in support of the Zone idea. And yes, carrying things from one space to another has nothing to do with whether you use Zones or ports ( more below on Personal Spaces ). Here are the problems I see with continuing to use only Ports. Saying you have 10 major worlds, each of with have 10 sub locations. By sub location, I mean you walk are walking around outside, then you come to a castle. Walking inside the castle brings you to a sub-location, basically its own scene. That's a total of 100 ports on your server. Now say you have 1000 users ( that's what we are shooting for right ). Now you have a total of 1100 ports on your computer waiting for requests. Furthermore, when if there is no program listening on those ports to hear the connection, then there is no connection. Hence we would need about 1100 instances of the server running to accomodate. Not even remotely possible. A fix: Have one super server that first receives all requests on port 8500. It then checks to see if the particular port the client is trying to reach has a server running. It then starts up the server at that port, and then there is a connection. Slow, but not inconceivable. How's this? every single time a user wants to move from one location to another, it requires instantiating a new TCP connection. TCP connections take both time and memory. Can a computer support this many simultaneous TCP connections? Quiet down these troubles and I'll drop the Zone idea. Personal Space: I absolutely want Personal Spaces. Why? What is a personal space, but a database of your own objects. If we were not to use these spaces, then essentially we would have to create a database in each User object. Classically recursive. The situation begs for a it. >>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(). Sounds good! >> 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... Why use Xj3D, an IE window and Contact with you logged in does this ?!? You edit server properties online! >>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. Yeah I would like to make VRSpace as close to the developer as possible. >> 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. Universal ID is clearly not going to be an issue for a while. I like the way you put it here you@yourhost. What I didn't like before is that Gates seemed to work like, once you gate you become you@lastgatinghost, which doesn't make any sense. If you are always you@yourgateway, then it sounds pretty unique. >> 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. Absolutely, I started looking at JXTA yesterday and soon realized that this is much more appropriate (and easier to implement) through that. Take care, Rob >------------------------------------------------------- >SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media >100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 >Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. >http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 >_______________________________________________ >Vrspace-dev mailing list >Vrs...@li... >https://lists.sourceforge.net/lists/listinfo/vrspace-dev |
|
From: Josip A. <jo...@vr...> - 2004-09-02 19:12:11
|
Rob Meyers wrote: > > This questions concerns whether to link spaces together one after > one as you visit them, or to always have two hop connection: first to > your gateway, and your gateway to the current space. ... Yeah I'm aware of arguments. Yeah, it's slow. But - why? Mostly cuz we have zillion of http requests - one for each object we check. Then again, you don't have to pass the same way thru gates to reach the destination. You should 'bookmark' the destination - remember ip, port etc. and connect directly. Now maybe you can't connect directly cuz destination has dynamic ip, then you have to bookmark it's PassiveGate/RemoteGate/whatisitcalledanyway (or something) on the gateway (vrspace.org). The way it is, it's about content (and metadata!) distribution. And here's this very concrete example:) So, Joe writes first person shooter. Rob built his very first aggressive avatar and wants to give it a try. So, Rob connects to vrspace.org and passes to Joe's space - can't connect directly cuz Joe has dynamic IP. All parties (Rob,Joe,vrspace.org) run web servers within vrspace servers. So, Joe gets new avatar (when he saw Rob he's got it in the cache) and Rob gets new code (actually you get that with WebGate, exec distribution is far future), while vrspace.org gets both new code and new avatar. They all get all the new stuff. Including new versions of vrspace.db which contains all the metatadata of all the space. Version control? IMHO not necessary - HTTP If-Modified-Since will do. Collaboration. The other thing is, information is there where required. We actually eliminate hops this way. And yet another, you don't have to upload anything anywhere, it's all transparent and once anyone saw it it's available to anyone else. Sure, these are my dreams. Status is: we have Gates, I just wrote caching http proxy, and we need only the way to search the stuff. Guess I should concentrate on NeuroGrid finally. Then we have all the components, and just need a couple more years to make it work;) This doesn't have much to do with the client, it's about standalone: I wanna run my local server, allocate few gigs for caching all I fetch via http, pop3 or nnrp, meaning all the information/content I get, and never search for it again. > Ports versus Zones: > > I am completely in support of the Zone idea. And yes, carrying > things from one space to another has nothing to do with whether you use > Zones or ports ( more below on Personal Spaces ). Here are the problems > I see with continuing to use only Ports. Saying you have 10 major > worlds, each of with have 10 sub locations. By sub location, I mean you > walk are walking around outside, then you come to a castle. Walking > inside the castle brings you to a sub-location, basically its own > scene. That's a total of 100 ports on your server. Now say you have > 1000 users ( that's what we are shooting for right ). Now you have a > total of 1100 ports on your computer waiting for requests. Furthermore, > when if there is no program listening on those ports to hear the > connection, then there is no connection. Hence we would need about 1100 > instances of the server running to accomodate. Not even remotely possible. Hey, but this is plainly wrong implementation of subspaces. I'd do that with filters: filter out events comming from outside the room, don't let events to people not in the room, etc, can filter on user coordinates or room name or some general ZoneFilter. > A fix: Have one super server that first receives all requests on > port 8500. It then checks to see if the particular port the client is > trying to reach has a server running. It then starts up the server at > that port, and then there is a connection. Slow, but not > inconceivable. How's this? every single time a user wants to move from > one location to another, it requires instantiating a new TCP > connection. TCP connections take both time and memory. Can a computer > support this many simultaneous TCP connections? Quiet down these > troubles and I'll drop the Zone idea. Wrong again - that's what PipedConnection is for;) Though you just gave me some thought... see, you could make such kind of Gate that runs another server. Though it needs not be org.vrspace.server.Server at all, you can use org.vrspace.server stuff like lib. BTW, 1000 connections isn't _that_ much, you get these on irc servers etc. Sure it's a lot for a FPS but not for a MUD, etc. > Personal Space: > > I absolutely want Personal Spaces. Why? What is a personal space, > but a database of your own objects. If we were not to use these spaces, > then essentially we would have to create a database in each User > object. Classically recursive. The situation begs for a it. Right. And I want my own database;) And my personal space, but on my box. You already have it, right? Look, everyone can freely run their own servers/spaces on their boxes, once they pass thru us we distibute their content for free. They wanna their server on our server, they gotta pay - 70 memberships buys one server, and I have no problems having 70 vrspace servers on one server with one db server handling 70 databases. So, for this to happen, we need just a bit code (personal eddition with easy installation, bookmarks etc) and some more organization, like membership cards and who will do what and such. Then, some marketing on lists and groups and forums... I mean, if you can buy it for $40 a year it's really not worth the effort;) > Why use Xj3D, an IE window and Contact with you logged in does this > ?!? You edit server properties online! Calm down, I was just testing;) But yeah, this is why this src/xj3d does. Tought I need server console, so why not do it in 3d? 2d = 3d - 1d after all:) Well xj3d doesn't handle vrml good, but it's a java3d Component... ... in more details: VRML is hot for database visualization: you never get relations drawn well in UML cuz it's 2d, and arrows always cross each other. So, why not draw boxes and arrows in 3d? You can visualize row numbers (box height), col number (box width) etc, then just put some TouchSensor to edit table sql or something. Did some code too, examine DatabaseMetadata and stuff and generate vrml. It's all boxes and arrows, gonna work fine even in xj3d, which is a Component after all:) Suppose you run 70 vrspace servers and 70 databases on your box, how would you put it in 3d? So that was the idea. Hacked a bit, everything is _much_ easier if you have access to Client and VRObject and Component and alltogether. Only if it worked:) > Yeah I would like to make VRSpace as close to the developer as > possible. Guess we'd do it much better than close for users:) Cuz that's we do every day... that's how I made that James - I need mail every day, used to run vrspace server starting 'run' ant target from jEdit... one big still missing from my point of view - I need ClassLoader able to unload classes and load new versions in runtime, and the appropriate Commands. Now it's a big deal cuz you can't unload class just like that cuz everyone keeps references to everything so you need to lock and cleanup, and this is about Transaction and VRObject.lockClass() and other long stories. Guess we could use local 'shutdown' command. Something that doesn't do System.exit() but calls Server.shutdown(). Then make targets for integration with jedit, eclipse etc. > Universal ID is clearly not going to be an issue for a while. I > like the way you put it here you@yourhost. What I didn't like before is > that Gates seemed to work like, once you gate you become > you@lastgatinghost, which doesn't make any sense. If you are always > you@yourgateway, then it sounds pretty unique. Well yeah, that's kind of handshake: you login to some host on some gate thru gate thru gate and get some you@gate1@gate2@blah login. He remembers you like that and you keep this on your disk. Sure, digital key exchange and stuff, sometimes, maybe:) > Absolutely, I started looking at JXTA yesterday and soon realized > that this is much more appropriate (and easier to implement) through that. Well, ages ago Alejandro suggested JINI for server community. JINI is no more, but JXTA is, so...:) Though we planned this for V2:) And I still think so, OK let it be here but we have a lot of other things to do, let em make something better in the meantime. BTW new JXTA out today. Regards... |
|
From: Rob M. <ro...@vr...> - 2004-09-05 18:49:35
|
Well, most of the stuff sounds good. Specially like the db vis
concept. However, I am still a firm believe in not linking multiple
connections. It is simple though, we will build and find out what works
and what doesn't. I have to take a look at Gates again as you said they
are working. I don't really want to touch your gate code cuz you seem to
have a different long term view than I. If they work with what I am trying
to do than I'll be happy to use it :) If not, I'll continue developing
more along the lines of Portal. I won't do any Zone work till I can't see
any other way, and that would probably be a long while. The personal user
database however will be the first thing I will be attacking. K, sounds good.
Rob
|
|
From: Rob M. <ro...@vr...> - 2004-09-05 19:37:41
|
Just tried to get the new gates from cvs, doesn't seem to be any changes since I last checked things in, please commit. |
|
From: Josip A. <jo...@vr...> - 2004-09-06 08:40:50
|
Rob Meyers wrote: > Just tried to get the new gates from cvs, doesn't seem to be any changes > since I last checked things in, please commit. Well, coulnd't pay my bills so ISP turned me of:) Now need to comment out portions of code to compile... coming. Anyway, I'll describe the functionality, hope to get some input. To enable it, just set http proxy in your web browser to localhost 8081 and that's it. Then what happens. Proxy fetches each and every requested doc and stores it to (hardcoded) <vrspace install dir>/cache/<protocol>/<server>/<path> i.e. cache/http/www.vrspace.org/index.html for later reference. On subsequent requests, it does not attempt to retrieve the content from the original location for some time, default 24h. This is _not_ http compliant: spec sez proxies are required to take into account expires and if-modified-since. But, maybe 20% of content is usefull information, while the rest are adds and other BS (according to eddie's measurement). Adds tipically have expires set to 15 mins, and browsers reload them again and again till we close the window, meaning we waste bandwidth even when we went for lunch... this bandwidth-saving strategy is borrowed from squid setup used in my LinProxy distro;) But it can lead to trouble. Usual way out of it is to hit reload button. Though I'm not sure we can use this approach for our purposes: I don't want to reload all the vrml, I want only say one specific avatar. Sure, one way is to set timeout low, say 15 mins, but then there's little use of cache. Well, open issues. Proxy also stores all the http metadata. Should store them to DB, so far only keeps them in memory. Most important is the content-type, but proxy needs them all: last-modified, expires, etc. And there's more to it. During download html and xml (wml, openoffice, ...) documents are parsed, sure we should parse vrml too. You wanna search, you gotta see what's inside. So far I look only for external references, with the intent to check broken links, maybe download textures and pics along with document etc. Actually, I hoped to rewrite all the urls to refer to locally stored copies rather than originals. This would allow me to open docs directly from the filesystem. But this leads to trouble: browser then requests local textures and pics instead of original ones. So I dropped the idea. Meaning there's dead code inside. But this code aims to wget functionallity... dunno, let's leave it there for a while, maybe we'll need it. OK, parsing continues. This part will wait for NeuroGrid implementation: document title will be stored to NG DB as <url> IS_RELATED_TO <keyword>, document body will (optionally) go with <url> CONTAINS <keyword> etc. So when you search the net, you first search all the stuff you've ever seen, then ask google. Well, whoom you ask depends on where you usually find what you're looking for, but that's another long story. And some implementation notes. A new package, org.vrspace.vfs - virtual file system. I don't like it much, but org.vrspace.server got too crowdy:) This parsing stuff requires com.arthurdo.parser package, so you won't be able to compile it unless you copy com.arthurdo from src/chisel to src/main. Don't like that neither... furthermore, NG uses another html parser by Somik Raha. A mess:))) In short - how to parse html? Regards... |
|
From: Josip A. <jo...@vr...> - 2004-09-06 08:40:56
|
Rob Meyers wrote: > Well, most of the stuff sounds good. Specially like the db vis > concept. However, I am still a firm believe in not linking multiple > connections. It is simple though, we will build and find out what works > and what doesn't. I have to take a look at Gates again as you said they > are working. I don't really want to touch your gate code cuz you seem > to have a different long term view than I. If they work with what I am > trying to do than I'll be happy to use it :) If not, I'll continue > developing more along the lines of Portal. I won't do any Zone work > till I can't see any other way, and that would probably be a long > while. The personal user database however will be the first thing I > will be attacking. K, sounds good. Sounds good to me too. Gates still require suspend/resume to work properly. I can't honestly say they work cuz I didn't try for ages:) But OK now I'll do some bugfixing, namely Gate and proxy. Have home LAN with linux, xp and 98, gonna setup small vrspace community. Regards... |
|
From: Arni B. <ar...@vr...> - 2004-09-08 22:57:28
|
Hi Ka & everybody I have finaly decided to learn how to upload to vrspace but.... i'm clueless= . A few questions related to your easy uploading page 1. Why not uppercase filenames or extensions? 2. Where do I download Chisel? And how do I start it? Have to start it from= =20 command prompt? Is Microsoft Java virtual machine enough? I have downloaded some version of chisel yesterday (not from vrspace, can't= =20 run it) but I think Joe wrote something that he changed chisel to have=20 direct upload to vrspace. 3. Fifth, place your Object to 0-0-0 Coordinates in your 3D Program, and be= =20 sure that its coordinate-scale isn=B4t huge, which means the farest edges=20 should be in 100 - 300 meters or units distance . Why this, the farest=20 edges, I mean? 4. General uploading question - I remember when we tested the virtual=20 Zagreb I made one large VRML and the uploader devided top level transforms= =20 into separate objects which all became the different VRML files/objects=20 going into database so they can be loaded/unloaded in real time according=20 to the viewers position. Whats the procedure now related to this issue? One= =20 master wrl file with a lot of referenced inlines? I want to update VR Zagreb so I just have to know the best way to do it. Thanks Bye |