This is a feature request for a new object in Second Life. The object will appear, act, and can be manipulated like the the normal script file - except - the script only runs on the client side and not on the server! Here's the new deal, the script can be edited by the normal script editor, but it won't be compiled by the LSO. The compilation is done by a customized client. To the server, the object appears as a persistent data object, as a script does now. The client has the option to download all the data from that object (given permission) and use to for its client-side applications. The client can than update the data, just like how a normal scripts runs and updates its data space. The new feature does not make any requirements to what the client implementation has to be except the API to retrieve and update the data as needed. The client may be running a python interpreter, and it downloads the CSPDO, which is a script to display a UI under the pyhthon language. The CSPDO is not specific to any particular language like python, as it could be C#, or Java, or something else. I'm just saying it is a separate issue for the client to recognize the data in the CSPDO. As a first implementation plan, the CSPDO could be accessible by the user's inventory. The client would have to be smart enough to find the CSPDO in the inventory. As a second implementation plan, the CSPDO could be located in a prim. When the prim is attached to the HUD, the CSPDOs inside those prims become available for the client to access. There are many requests for a plug-in architecture. This is just a request for a new feature to implement the server side for a persistent data object in the very likeness as server scripts except as noted above.