[Pipet Devel] chat

[Brad Chapman]

[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