updating your SL scripts directly from your C: drive using XMLRPC?

It would be great to maintain scripts on your C: drive using an appropriate editor, then click a button to have them automatically update your objects in SL . My thoughts were that:

(i) use of ANT to facilitate a TAG based approach for copying common funntions into scripts - i.e. source area never has repeated code, but when it builds (i.e. creates a new set of scripts in the build area that are the final/complete set, with the tags being populated with the common functions that they refer to) e.g. use of an ANT function such as
<filter token="<TAG:xxxx>"> value="${property.Containg.The.Desired.String}"/>

(ii) Have a deploy to SL script that takes the scripts and sends to SL via XMLRPC. The source would need to save knowledge of the various scripts which which SL objects they would need to be populated within.

(iii) There would an update object in SL near all your objects that then receives all the updated scripts, finds their target object, then updates them - I guess??

Question - Regarding (iii) is there a way in SL via LSL to update an object's script? E.g. if there were 4 scripts in a prim + 1 script to do the update function, could this latter script have a way to get the new script data and replace/update any of these 4 scripts?

Tks

There is no normal way to automate the creation of a LSL script - while you can send data, you cannot write to a "script", you still need to do with the standard way to create/save scripts. You could perhaps be able to create a program to automate the SL Client, however that is probably more of a pain in the rear than it is worth, IMHO. I wish there was a nice way, but I think LL fears giving us a way to automatically create assets.

Of course once the script is saved as an asset, there are ways to update multiple objects with the script, but that is not quite what it sounds like you want to do.

One thing I have explored (and have working to some extent) is creating a virtual machine within SL and then use rpc to send code to the virtual machine. Of course, this can be painfully slow though since LSL is slow enough as is without it parsing yet another language on top. In the script library is my Forth engine which is the most advanced publically available virtual machine in SL (to my knowledge). I have an improved version which departs from trying to be "true to the Forth language" in order to be more practicle and fast which I call 24th (Second Forth).