[Opensim-dev] Place for osFoo functions that only work with certain languages

[Rob Smart]

No I'm not confused about the difference between language and API  :)

I'm just talking at a higher level, the level of functionality.

If we are to stick rigidly to LSL then they must be functionally equivalent
which includes language and API access.

Otherwise an LSL script written in OpenSim cannot simply be cut and pasted
into SL and expected to run.

As I stated OpenSim has already gone past this point. If I come to OpenSim a
newbie and learn LSL there, then i register
with SL and try to transfer my scripts I'll suddenly discover they dont work
because i've used osXXXXXXXX API method.

On a seperate issue I wasnt aware that there is already a configuration
option to disable osXXXXXX extension functions (thanks Melanie)

And as Melanie stated anything using the osXXXXXX function is actually OSSL.


Rob

On Thu, Sep 11, 2008 at 11:03 AM, Mike Mazur <mmazur at gmail.com> wrote:

> Hi,
>
> On Thu, Sep 11, 2008 at 6:32 PM, Rob Smart <rob.s.smart at gmail.com> wrote:
> >> >>LSL is Linden Scripting Language, and the authority on this is Linden
> >> >>Labs. If we start adding new features to LSL, it ceases to become LSL.
> >> >>It becomes LSL++ or something like that.
> >
> > Agreed it does become LSL++, however i think that boundary has already
> been
> > crossed in OpenSim to a certain
> > extent by offering osSetDynamicTextureURL and other extension functions.
> The
> > scripts that use those are now not transferable back onto
> > the Linden grid as there is no possible way to replicate that
> functionality
> > there currently.
>
> I believe you are confusing language and API.
>
> osSetDynamicTextureURL() is an addition to the API provided by
> OpenSim. All those llFunctions() are the standard Linden Labs API.
> OpenSim provides additions to this API in the form of osFunctions()
> that script authors can use.
>
> A parallel to this is .NET: it provides a class for dealing with URIs.
> This is built in to the standard .NET and Mono distributions. However
> .NET doesn't provide XML-RPC functionality, so OpenSim uses a
> third-part library for this. The functions provided by that
> third-party library are available for use anywhere within the OpenSim
> codebase, but that same code won't compile elsehwere without that
> library being present.
>
> Think of it this way, osFunctions() just provide more built-in
> functions for you to use. You can even define your own custom
> functions in your LSL script directly, and calling functions is
> natively supported by the language. It is not LSL++, it's still 100%
> pure LSL; none of this actually changes the language itself.
>
> Supporting additional datatypes in LSL is much different. Now we're
> talking about LSL++. Now we have to edit the very definition of the
> language, its grammar, perhaps adding new keywords.
>
> Let's assume we do this, and sometime down the road LL releases LSL
> 2.0 with a few extra features. It's entirely possible that those new
> features will be incompatible with the extensions we've implemented.
> That's a situation I would *not* like to be in ;)
>
> Mike
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080911/34c27c74/attachment-0001.html>