[Opensim-dev] Changes needed to DotNet engine to make use of shared LSL and OSSL

[Kyle Hamilton]

No matter what script languages are implemented, there are certain
things that are going to have to be done by each call (certain
permissions checked, certain object methods called, certain things
changed, and only then the final 'commit' of the command).

If I could inject a very small request, could the permissions and
prerequisites for each script command be explicitly documented in
comments?  If we're going to fork the implementations into different
files, I'd very much like new script-language designers to know what
actually needs to be done to verify that the appropriate permissions
exist.  (The reason for this is because there are other languages,
such as LISP and Scheme, that I'd like to see the ability to support.
They change the rules of interpretation, compilation, and how they do
various things -- enough that trying to support them without a
well-defined permission policy for reference would cause them to open
up security holes.)

I work with a MUD software that implements two separate languages,
implemented at two separate times, which have had some particularly
and peculiarly disastrous security interactions.  If there's going to
be some kind of implementation forking, I'd much rather put this
particular knowledge (of the mistakes which have been made by others
:P) out for the OpenSim community to know about, learn from, and avoid
the mistakes of.

-Kyle H

On Tue, Jul 1, 2008 at 3:13 PM, Charles Krinke <cfk at pacbell.net> wrote:
> Dear Kr:
>
> The key issue seems to be that the file LSL_BuiltIn_Commands.cs contained
> all our C# subroutine implementations for the 328 LSL commands. Now that
> file has been copied and morphed.
>
> So, my suggestion is to take the common parts of the existing file, and the
> copied and morphed file and put them into a third file. That third file
> might be LSL_Api.cs.
>
> In any case, it seems to me that whatever unique parts are appropriate for
> the new scriptengine implementation and unique parts for the existing script
> engine implementation then reference the namespace of the common file,
> whatever we wish to call it.
>
> In the common file are all the things like llSay(), llCeil(), llFloor() that
> just are wrappers around C# subroutines. In fact, 85% of the original
> LSL_BuiltIn_Commands.cs and the new, copied file are identical.
>
> So, I would say, lets have an interface, or a derived class, or whatever you
> feel comfortable with and just move forward.
>
> The most important thing to me in this whole controversy right now is to not
> have two identical copies of hundreds of little subroutines.
>
> Charles
>
> ----- Original Message ----
> From: krtaylor <krtaylor at linux.vnet.ibm.com>
> To: opensim-dev at lists.berlios.de
> Sent: Tuesday, July 1, 2008 2:48:26 PM
> Subject: [Opensim-dev] Changes needed to DotNet engine to make use of shared
> LSL and OSSL
>
>
> As per the discussion on irc earlier today, I agreed to summarize the
> plans to move forward with separating LSL from the current DotNet
> engine, to make use of the shared structures proposed with the new
> xengine. This isn't complete by any means, but meant to start an email
> discussion.
>
> The current DotNetEngine needs to be changed to make it able to process
> events and share LSL and other languages via API files:
>
> 1. Use the IScriptEngine and IScript interfaces to support a per
> instance object in the ScriptManager
> - changes to refactor IScript using the AppDomainObject (IScript) from
> Shared and to rescope the existing IScript to IScriptInstance and move
> outside AppDomain
>
> 2.Use  EventParams and DetectParams
>
> I have been toying with the idea of either patching the DotNet engine or
> just porting the DotNet enhanced functionality to a XEngine clone for a
> new DotNet base. Since we are already proposing isolating the languages
> there is certain advantages to the later. The former would leave some
> problems to fix, which have already been resolved in the XEngine. Either
> way, I think a fork to a 3rd engine would be the best approach. This
> would allow others to get involved, and retain both engines as they are
> today, and not break everyone all  by simply having a 3rd engine for a
> while.
>
> Comments?
>
> --
> Kurt R Taylor (Kurt Stringer)
>
> Open Virtual Worlds Development
> http://opensimulator.org  http://opensim.ibm.com
> International Business Machines, Corp.
> (512) 838-2496    T/L:  678
>
>
> _______________________________________________
> 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
>
>