[sldev] Opening the server source?

Mike Monkowski monkowsk at watson.ibm.com
Mon Jul 2 15:53:47 PDT 2007


Adam,

I guess "message server" was a poor choice of terminology.  Perhaps 
"transaction server" would be more descriptive.  The transaction server 
would do the processing that the current sim server does to generate 
messages to the other servers.  Some may be simple pass-through, but the 
current "trusted" processing that the current sim server does could 
still be done on LL transaction servers.

Having specialized per-service proxies leaves you with concurrency and 
rollback problems, leaving more computation in the viewer, which of 
course, is not trusted.

Yes, the scripts may be visible to the physics server, but scripts are 
code, and, well, this is an open source project.  If you choose, you can 
disallow your main grid scripts from being exported to private sims and
vice versa.

Open sourcing just the physics and scripting could generate a lot of 
creativity.  I'd hate to have to wait for a complete open source server 
before being able to do anything.  That could be a very long time.

Soft Linden said,
> 2) If you can point to specific modules of the sim that you'd like to
> see and can help me with an argument for getting them open sooner, I'm
> all ears.
I'm asking for physics and scripting.

Mike


Adam Frisby wrote:
> ...having a server manage connections for the client strikes me as somewhat 
> unneeded complexity since all it is doing is proxying the connections; 
> which could be served better by having specialised per-service proxies.
> 
> Adam
> 
> Mike Monkowski wrote:
> 
>> Actually, I was suggesting something between these two.  By breaking 
>> the sim into a message server and a physics server, you don't have to 
>> change the rest of the architecture.  The viewer sees no change.  The 
>> specialty servers see no change.  One box is just split into two with 
>> the rest of the connections remaining intact.  It should be a lot 
>> easier to implement.
>>
>> Mike


More information about the SLDev mailing list