<div dir="ltr">No I'm not confused about the difference between language and API  :)<br><br>I'm just talking at a higher level, the level of functionality. <br><br>If we are to stick rigidly to LSL then they must be functionally equivalent which includes language and API access.<br>
<br>Otherwise an LSL script written in OpenSim cannot simply be cut and pasted into SL and expected to run.<br><br>As I stated OpenSim has already gone past this point. If I come to OpenSim a newbie and learn LSL there, then i register<br>
with SL and try to transfer my scripts I'll suddenly discover they dont work because i've used osXXXXXXXX API method.<br><br>On a seperate issue I wasnt aware that there is already a configuration option to disable osXXXXXX extension functions (thanks Melanie)<br>
<br>And as Melanie stated anything using the osXXXXXX function is actually OSSL. <br><br>Rob<br><br><div class="gmail_quote">On Thu, Sep 11, 2008 at 11:03 AM, Mike Mazur <span dir="ltr"><<a href="mailto:mmazur@gmail.com">mmazur@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br>
<div class="Ih2E3d"><br>
On Thu, Sep 11, 2008 at 6:32 PM, Rob Smart <<a href="mailto:rob.s.smart@gmail.com">rob.s.smart@gmail.com</a>> wrote:<br>
>> >>LSL is Linden Scripting Language, and the authority on this is Linden<br>
>> >>Labs. If we start adding new features to LSL, it ceases to become LSL.<br>
>> >>It becomes LSL++ or something like that.<br>
><br>
> Agreed it does become LSL++, however i think that boundary has already been<br>
> crossed in OpenSim to a certain<br>
> extent by offering osSetDynamicTextureURL and other extension functions. The<br>
> scripts that use those are now not transferable back onto<br>
> the Linden grid as there is no possible way to replicate that functionality<br>
> there currently.<br>
<br>
</div>I believe you are confusing language and API.<br>
<br>
osSetDynamicTextureURL() is an addition to the API provided by<br>
OpenSim. All those llFunctions() are the standard Linden Labs API.<br>
OpenSim provides additions to this API in the form of osFunctions()<br>
that script authors can use.<br>
<br>
A parallel to this is .NET: it provides a class for dealing with URIs.<br>
This is built in to the standard .NET and Mono distributions. However<br>
.NET doesn't provide XML-RPC functionality, so OpenSim uses a<br>
third-part library for this. The functions provided by that<br>
third-party library are available for use anywhere within the OpenSim<br>
codebase, but that same code won't compile elsehwere without that<br>
library being present.<br>
<br>
Think of it this way, osFunctions() just provide more built-in<br>
functions for you to use. You can even define your own custom<br>
functions in your LSL script directly, and calling functions is<br>
natively supported by the language. It is not LSL++, it's still 100%<br>
pure LSL; none of this actually changes the language itself.<br>
<br>
Supporting additional datatypes in LSL is much different. Now we're<br>
talking about LSL++. Now we have to edit the very definition of the<br>
language, its grammar, perhaps adding new keywords.<br>
<br>
Let's assume we do this, and sometime down the road LL releases LSL<br>
2.0 with a few extra features. It's entirely possible that those new<br>
features will be incompatible with the extensions we've implemented.<br>
That's a situation I would *not* like to be in ;)<br>
<div><div></div><div class="Wj3C7c"><br>
Mike<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br></div>