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

[Charles Krinke]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080701/ab6b9ecd/attachment-0001.html>