Method for Opening Client Without Releasing Too Much Source

Two ideas, no reason both cannot be implemented.

1. Embed the Python inperpreter in the client.
   
2. Embed the client in Python.
   

1. Python is
   1. a high-level object-oriented scripting language,
      
   2. useful for rapid prototyping,
      
   3. free,
      
   4. open-source,
      
   5. included as a standard feature in most major Linux distributions,
      
   6. community-driven,
      
   7. community-developed, and
      
   8. depended upon heavily by Google, who employs the language`s creator, where he is expected to devote approximately half of his on-the-clock time to language development.
      
   
   
2. The major building blocks of the client, i.e., the interface to the various server-side and client-side subsystems, should be exposed as Python "type" and "instance" objects [some as "singletons" and some as "user-instantiatable" objects].
   
3. The curent client configuration would be re-implimented as Python code, using the above-mentioned objects as building blocks, allowing people who like things "as-is" to ignore the new functionality and not need to learn another scripting language.
   
4. This would instantly give nearly everyone nearly everything they want out of the client with very little work on the part of the development team, while still preserving the "trade secret" status of critical components.
   

I know that this would be significaltly more involved than the above, but while we`re at it, why not embed Python in the server as well, as an alternate server-side scripting language?

Toodle-oo!

<Obligitory comment about the shortcomings of Python and the merits of Ruby)
Seriously though, adding a public Client Inteface API would be awesome.

Seriously, I picked Python because I know that Python is designed both to be imbedded into applications as a scripting language and to embed applications into with the ability to use multiple embedded applications within the same program, something which I do not know about Ruby [even though that may be the case], or any other language, for that matter.

Besides, I program in Python, and I don`t know Ruby. [Who is she, anyway?]

I`d like to see the client released both as an embedded aplication and as a stand-alone with embedded Python. Heck, the embedded application could even be part of the stand-alone application!

Now wouldn`t that be cool?

Toodle-oo!

The snowcrash software donated to our reverse engineering wiki (http://labs.highenergychemistry.com/slprotocol/) allows you to essentially do this. You can install hooks for any packet type in Second Life, and read, modify, or inject data in to the network stream. It's an extremely powerful debugging tool and allows you to write your own custom client piggybacked on to the official one. It's written in C++ but if you want to integrate a Python/Ruby interpreter in there please send us diffs!

I`d love to see an Python-integrated client, but I am unable to provide diffs. I would reccommend, suggest, and request that someone at your end check out the Python website, particularly the section on Extending and Embedding. While you are at it, I`m sure many people would be grateful if you could build a client that runs on Win98.

Well, Ah guess that`s `bout it fer now. Toodle-oo!

Hi,

are there any news on the progress of this matter? I would appreciate any info on this a lot.

Cheers!

I would imagine it's irrelivant now since the client has already been opensourced: http://blog.secondlife.com/2007/01/08/embracing-the-inevitable