[Opensim-dev] Should the core OpenSim distribution carry manyscripting languages?

Belxjander Serechai belxjander at gmail.com
Mon Jun 2 15:42:04 UTC 2008


Easier to have regions in a grid all support a functional set or
"common" language with the compiled requirements,
  I would recommend LSL as the pre-requisite declaration of functional
requirements and C# as being extending that

This also introduces a restriction for interconnection region<->region
and also grid<->grid making some objects,
  region or grid specific...the content creators may enjoy that poor-mans DRM

On Tue, Jun 3, 2008 at 12:22 AM, Mic Bowman <cmickeyb at gmail.com> wrote:
> i admit to being somewhat addicted to C# scripting now so i'd second the
> vote for LSL & C#.
>
> however, there is another question here... long term, how do you manage
> interoperability between regions when the different simulators support
> diverse scripting engines? the simple answer is "you don't"... the only
> region an object should be expected to behave correctly is the one in which
> it was created. that approach, however, seems somewhat... unsatisfying
> (sarcasm intended) unless you are will to assert that all simulators in a
> grid will provide the same capabilities.
>
> two other alternatives come to mind...
>
> first, there is a single standard "intermediate" representation which all
> the various scripting engines translate into. this would have to include a
> common set of APIs (eg the LSL and OS functions currently supported). today,
> C# is that intermediate representation and, so long as the C# is what's
> passed from region to region, it should work (that does mean that the assets
> should store both the native script and the translated c# or whatever the
> intermediate representation in order to ensure portability).
>
> a second alternative is to negotiate script representations on region
> crossing. the new simulator supports some languages/APIs, the object
> requires some set of functions, and they negotiate a behavior. that could
> get pretty ugly, but given that there is no way to control what extensions
> one region provider will support, there will have to be some capability
> negotiation (even if the outcome is as simple as "this region can't support
> that object").
>
> thoughts???
>
> --mic
>
>
> Kurt Taylor wrote:
>
> Agreed, I'd vote to only ship LSL. Maybe C#. Everything else optional.
> CPANish repository would be perfect.
>
> krtaylor - Kurt Taylor
>
>
> opensim-dev-bounces at lists.berlios.de wrote on 06/01/2008 10:45:48 PM:
>
>> I'm personally quite in favour of us developing a CPAN-like repository
>> for OpenSim modules. To me it makes a very good deal of sense.
>>
>> Regards,
>>
>> Adam
>>
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de
>> [mailto:opensim-dev-bounces at lists.berlios.de] On Behalf Of Justin
>> Clark-Casey
>> Sent: Sunday, 1 June 2008 8:44 PM
>> To: opensim-dev at lists.berlios.de
>> Subject: [Opensim-dev] Should the core OpenSim distribution carry
>> manyscripting languages?
>>
>> Hi there,
>>
>> Last week, Kinoc was kind enough to write an implementation of Yield
>> Prolog where YP is translated into underlying C# for compilation (in the
>>
>> same manner as our current LSL support).  This patch was included in
>> OpenSim in r4927.
>>
>> I have nothing against Prolog (admittedly I have never had the chance to
>>
>> pick up) and certainly nothing against Kinoc.  However, I am concerned
>> that by including many scripting languages in the OpenSim core
>> distribution (if Prolog, why not Javascript, Ruby, Python, etc, etc.) we
>>
>> incur more negatives than positives.  Firstly, I'm concerned that a
>> proportion of this code (particularly that which no core committer has
>> an interest in) will at some point slip into decay, particularly if the
>> original contributor has moved on to other things.  We've already seen
>> this happen with other areas of the code, such as the MSSQL database
>> support.
>>
>> Secondly, if individual language modules do need to change in response
>> to other OpenSim changes without a decay option (for example, in order
>> that they can still compile), this places a higher burden on the core
>> committers and makes it more costly to enhance the codebase in general.
>>
>> Thirdly, I'm concerned that the more code we have of this nature
>> (particular code which compiles script into c#), the more potential
>> security holes we have.  This isn't too much of a concern right now but
>> will be come more of an issue in the future.
>>
>> Therefore, I would argue that OpenSimulator should only include in its
>> core distribution support for a few scripting languages.  In my opinion
>> these would be LSL, maybe C# and possibly one other (maybe Python).
>> Support for other languages would come as optional plugins, available
>> either directly from the author or from some satellite repository
>> (perhaps similar to Perl's CPAN or PHP's PEAR).  I would personally
>> prefer to see the core OpenSim distribution kept relatively lean and
>> mean.
>>
>> If necessary, I am happy to make any necessary infrastructure changes to
>>
>> make language plugins possible/easier (which probably also means making
>> much needed enhancements to the plugin system).
>>
>> What do other people think?
>>
>> Regards,
>>
>> --
>> justincc
>> Justin Clark-Casey
>> http://justincc.wordpress.com
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
> ________________________________
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>



More information about the Opensim-dev mailing list