|
Well, if they already have the compiler,
and a custom version of Mono, that may be an option. However, maintaining that
custom version of Mono is going to be a headache. This is a maintenance
nightmare. Every time a security hole pops up, they must separately code a
patch for their own custom version. And that doesn’t even touch on the future
list of new features they will undoubtedly never see. Forking code is never a
good idea, especially if you have a small team to maintain things. They should
let the Open Source model work for them, instead of working against it. Let
the Mono team do what they do best. Use the latest stable version as is. -Samuel Vincent From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Wilson I suggested that back when the Mono talk was a big deal on the forums.
The response I got was "We already have a LSL -> CIL compiler". If they already have a custom Mono engine running, with a class library
that only allows access to the things that LSL should have access to, then the
simplest thing is to simply compile straight to CIL. Going to C# would add
overhead, since some things in LSL (the state system, for example), don't
translate to C# at all. On 11/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Ah, that actually makes more sense. Emitting your own
CIL opens up a world of possibilities for security risk, as well as bugs.
However, my suggestion would be to make LSL compile to C#, possibly hidden from
the users, and have a carefully designed set of C# classes that implements
LSL's functionality behind the scenes. This would give you the full
performance of a C# application, the benefit of a rich feature set available in
.Net, and the security of being able to carefully control the subset of .Net
that is exposed to users. -Samuel Vincent From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Tom Wilson
I think
what he's saying that the virtual machine that runs LSL run inside of the .Net
CLR... if that IS what he's saying, it's unnecessary, since LL has
already implemented an LSL compiler for Mono. For some reason, though, they've
just never transferred it to the rest of the grid (it's only running on On
11/1/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
wrote: Perhaps I am misunderstanding what you just said. Are
you actually suggesting running the .Net CLR (.Net's virtual machine) on
top of a Java VM, thus giving us two nested virtual machines on top of the
native OS? -Samuel Vincent From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On
Behalf Of Jonathan One thing to note, I didn't mention my perspective
that would help explain my interest. A CLS, like Mono, usually implements
a runtime environment directly on top of a native environment. Given that CIL
is well defined, this direct implementation is not needed and can be divided
again with a VM, so that the CIL executable is within a runtime environment
directly on top of a VM instead of a native environment. This allows machine
states to be stored, retrieved, distributed, and networked across like or
different native environments. Current implementations of CLS (Mono and
Microsoft alike) are limited in their microthread abilities due to native
entanglements. The VM will solve that. It is expected this division will affect
performance, where many CLS implementers have touted native speed, at the trade
of such native speed in exchange for scalability and security. Java to CIL + C# to CIL = common sense
_______________________________________________ libsecondlife-dev mailing listlibsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/ --
_______________________________________________ libsecondlife-dev mailing listlibsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/ --
|
_______________________________________________ libsecondlife-dev mailing list libsecondlife-dev@gna.org https://mail.gna.org/listinfo/libsecondlife-dev http://www.libsecondlife.org/
