[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