<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
My experience with RESTComms, and having looked at the other modules in
there, is that most of those aren't really "modules" as in "optional
components", but as "the reference implementation of a required
interface that can be replaced with another implementation". For that
reason they can be seen as belonging to core, and be bundled in one
single dll.<br>
<br>
Although I would prefer to see each one of them in a separate dll, I
think MW's proposal is perfectly reasonable. It's a good idea to
separate these modules from, at least, OpenSim.Region.Environment.dll,
if not from each other.<br>
<br>
MW wrote:
<blockquote cite="mid:663727.6104.qm@web23003.mail.ird.yahoo.com"
type="cite">Putting aside the optimisations for now, as I think that
is a different question. As if we are going to have a dynamic module
system then those issues come with it.<br>
<br>
While I think having every module in a separate dll/project is too
much. As Stefan said I think we have just about enough projects in the
core as it is. But I can see a case for moving all the modules that are
currently in OpenSim.Region.Environment, into a single separate
project/dll called something like OpenSim.Region.CoreModules. <br>
<br>
And if we could as Justin said, impove the module loading system, so
that the operator can turn on and off the loading/usage of any modules
in a single dll. <br>
<br>
<b><i>Stefan Andersson <a class="moz-txt-link-rfc2396E" href="mailto:stefan@tribalmedia.se"><stefan@tribalmedia.se></a></i></b> wrote:
<blockquote class="replbq"
style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">
<style> .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Verdana } </style>
I think that some confusion stems from the fact that it's a difference
between referencing the assembly, and dynamically instancing classes
out of it.<br>
<br>
If you reference classes directly, as in<br>
<br>
mything = new Thing();<br>
<br>
where thing could be a module, albeit _referenced_, not _loaded_<br>
<br>
is a huge difference to<br>
<br>
mything = loadedAssembly.Instantiate( "Thing" );<br>
<br>
in the former, the jit compiler can do all kinds of neat optimizations
when referencing classes in the Assembly, since it has both the
referenced component and the referrer at hand. It can also inline and
optimize away type validity checks and trusted domain checks.<br>
<br>
In the latter, it really can't, and need to wrap everything in prudent
encapsulation, protection and indirection.<br>
<br>
Optimization points aside, I would hate for us to expand the core
modules into separate projects just because we can; I think we would
have to add 20 more projects to the solution and that would just suck -
especially now that we have cleaned out so many. Some of the these new
projects will have just a handful of classes, which is just an absurd
waste of resources for something that should be used in 95% of the
setups.<br>
<br>
I actually don't know how mono addins work, but in the .net framework
individual classes are referenced by assembly and class if loaded at
runtime, so for examble<br>
<br>
authModule= "MyAuthLib.dll, MyAuthenticator" would reference the class
MyAuthenticator in the dll MyAuthLib.dll - which means that you can
lump as many of those together in an dll that you want to.<br>
<br>
so we should make sure we can do something liket that, and instead try
to lump modules that share a common domain together.<br>
<br>
The only two reasons to ever split an assembly into two is from<br>
* references being too different (if you want to re-use them separately)<br>
* encapsulation and security issues (actuallly USING internal as it was
intended)<br>
<br>
So, what I'm saying is that we should strive towards a situation where
the core modules are bundled into a minimal set of assemblies, and the
rest put on forge.<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
> Date: Thu, 29 Jan 2009 11:28:19 +0100<br>
> From: <a class="moz-txt-link-abbreviated" href="mailto:DrScofield@xyzzyxyzzy.net">DrScofield@xyzzyxyzzy.net</a><br>
> To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> Subject: Re: [Opensim-dev] proposal: cleanup and break up region
modules<br>
> <br>
> Tleiades Lauridsen wrote:<br>
> > <br>
> > <br>
> >> Date: Thu, 29 Jan 2009 08:31:48 +0100<br>
> >> From: <a class="moz-txt-link-abbreviated" href="mailto:DrScofield@xyzzyxyzzy.net">DrScofield@xyzzyxyzzy.net</a><br>
> >> To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a><br>
> >> Subject: Re: [Opensim-dev] proposal: cleanup and break up
region modules<br>
> >><br>
> >> Tleiades wrote:<br>
> >> >> I'd be much more of a fan of having each module
a seperate dll. Files<br>
> >> >> are cheap too. :) And that makes it very clear
to people what they are<br>
> >> >> loading, and what they aren't loading.<br>
> >> >><br>
> >> ><br>
> >> > (On the fear of talking about performance
prematurely)<br>
> >> > Won't that cause problems for the JIT'er?<br>
> >> ><br>
> >> > Normally access to member variables gets optimized
away into a direct<br>
> >> > memory access rather than invocation of a JSR. If I
recall correctly<br>
> >> > this optimization does not work for dynamically
loaded assemblies.<br>
> >><br>
> >> well, if that's the case, then it's not working currently
either :-)<br>
> > currently<br>
> >> we lump all region modules into one large super DLL and
load that<br>
> > dynamically.<br>
> > <br>
> > I guess what I'm saying is that dll files are not as cheap as
it is<br>
> > being implied. Having an application dynamicallly load a
large number of<br>
> > dll's at runtime, is less efficient that loading a few large
dll's<br>
> > during load time. The JIT'ed code will be less efficient and
loadtime of<br>
> > the application will increase. While load time may not be a
big issue, I<br>
> > believe it is best to give the JIT engine the best working
condition.<br>
> <br>
> we are always loading at runtime --- or let me ask the other way
round: what do<br>
> you define as "loadtime"?<br>
> <br>
> <br>
> > <br>
> > As I understand it the JIT engine and assembly loader have
been designed<br>
> > based on a use pattern which states: "Most assemblies will be
loaded<br>
> > during application load time, and only few assemblies will be
loaded at<br>
> > a latter stage",<br>
> <br>
> well, we are loading at runtime then.<br>
> <br>
> -- <br>
> dr dirk husemann ---- virtual worlds research ---- ibm zurich
research lab<br>
> SL: dr scofield ---- <a class="moz-txt-link-abbreviated" href="mailto:drscofield@xyzzyxyzzy.net">drscofield@xyzzyxyzzy.net</a> ----
<a class="moz-txt-link-freetext" href="http://xyzzyxyzzy.net/">http://xyzzyxyzzy.net/</a><br>
> RL: <a class="moz-txt-link-abbreviated" href="mailto:hud@zurich.ibm.com">hud@zurich.ibm.com</a> - +41 44 724 8573 -
<a class="moz-txt-link-freetext" href="http://www.zurich.ibm.com/~hud/">http://www.zurich.ibm.com/~hud/</a><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
> <a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</blockquote>
<br>
<p> </p>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>