[snip ..central server conversation...] > Brad, if the Napster-like central server can be distributed with vsh, or at > least be made available publicly, then people can make peer-2-peer > connections. All they have to do is specify which 'Napster-like' server they > want to use as a filesystem, and it can be one on your buddy's computer. > > And I really see this Napster-like server as being vsh's filesystem. Heck, > if > we distribute this 'filesystem' with every copy of vsh, the filesystem can > hold your local nodes. But what we can do at The Open Lab is set up a large > repository of nodes...but use the same code that comes with every > distribution > of vsh. Jeff, I want to use vsh/loci as a "cheap cluster type thingy" to distribute groups of expensive time consuming processes over multiple computers. The idea of a central server mediating peer2peer connections in the napster manner you are describing is definately not compatible with this vision. I think the napster idea is great as a way to distribute "pre-built scripts" for running programs, and I definately support its use for this. But I don't see the point in having a central server mediating all of my connections among local machines. I think we will need some kind of central naming service server to distribute corba instances, but I want to keep a central server lightweight and disposable (ie. you don't need to connect to it if you can get the object reference in another manner). I really just don't see the need for a central server in the manner that you describe. Can you explain why you think it is better to funnel all connections through a server? > You know, even when you log on to IRC, you're using a central server to host > the connection between 2 computers. But you can choose one of many servers. > Why not do the same with vsh? IRC uses a central server to mediate a connection between two client computers. By contrast, each vsh instance is both a client (that can connect to other vsh instances) and a server (that can recieve requests from othe vsh servers). Lets just think about a simple conversation between two peers. The way I am envisioning it we can have a simple two way connection: vsh1 vsh2 ----- ----- client --> server server <-- client If we put things through a server we've got: vsh1 central vsh2 server ----- ------ ----- client --> server client ---> server server <--- client server <-- client I don't understand why we want to introduce this overhead. It seems unncessary, and like a lot of extra programming to get this central server going :) [snip...gms compilation...] > The problem with compiling GMS is that the location of a (gtk?) header in the > library changed since the version Jarl last compiled GMS with. That is the problem with building Makefiles by hand, you are almost guaranteed to have to hack them on another computer. It is nice that we will be able to try these things out on multiple computers, so hopefully we can get rid of some of the multi-platform differences early in the game. gms is almost nearly under the control of an autoconf/make build now, so hopefully things will be a lot nicer soon and everything will 'just build' in the proper gnome manner :-) Brad