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.
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.
MW wrote:
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.
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.
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.
*/Stefan Andersson <[email protected]>/* wrote:
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.
If you reference classes directly, as in
mything = new Thing();
where thing could be a module, albeit _referenced_, not _loaded_
is a huge difference to
mything = loadedAssembly.Instantiate( "Thing" );
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.
In the latter, it really can't, and need to wrap everything in
prudent encapsulation, protection and indirection.
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.
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
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.
so we should make sure we can do something liket that, and instead
try to lump modules that share a common domain together.
The only two reasons to ever split an assembly into two is from
* references being too different (if you want to re-use them
separately)
* encapsulation and security issues (actuallly USING internal as
it was intended)
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.
Best regards,
Stefan Andersson
Tribal Media AB
> Date: Thu, 29 Jan 2009 11:28:19 +0100
> From: [email protected]
> To: [email protected]
> Subject: Re: [Opensim-dev] proposal: cleanup and break up region
modules
>
> Tleiades Lauridsen wrote:
> >
> >
> >> Date: Thu, 29 Jan 2009 08:31:48 +0100
> >> From: [email protected]
> >> To: [email protected]
> >> Subject: Re: [Opensim-dev] proposal: cleanup and break up
region modules
> >>
> >> Tleiades wrote:
> >> >> I'd be much more of a fan of having each module a seperate
dll. Files
> >> >> are cheap too. :) And that makes it very clear to people
what they are
> >> >> loading, and what they aren't loading.
> >> >>
> >> >
> >> > (On the fear of talking about performance prematurely)
> >> > Won't that cause problems for the JIT'er?
> >> >
> >> > Normally access to member variables gets optimized away
into a direct
> >> > memory access rather than invocation of a JSR. If I recall
correctly
> >> > this optimization does not work for dynamically loaded
assemblies.
> >>
> >> well, if that's the case, then it's not working currently
either :-)
> > currently
> >> we lump all region modules into one large super DLL and load that
> > dynamically.
> >
> > I guess what I'm saying is that dll files are not as cheap as
it is
> > being implied. Having an application dynamicallly load a large
number of
> > dll's at runtime, is less efficient that loading a few large dll's
> > during load time. The JIT'ed code will be less efficient and
loadtime of
> > the application will increase. While load time may not be a
big issue, I
> > believe it is best to give the JIT engine the best working
condition.
>
> we are always loading at runtime --- or let me ask the other way
round: what do
> you define as "loadtime"?
>
>
> >
> > As I understand it the JIT engine and assembly loader have
been designed
> > based on a use pattern which states: "Most assemblies will be
loaded
> > during application load time, and only few assemblies will be
loaded at
> > a latter stage",
>
> well, we are loading at runtime then.
>
> --
> dr dirk husemann ---- virtual worlds research ---- ibm zurich
research lab
> SL: dr scofield ---- [email protected] ----
http://xyzzyxyzzy.net/
> RL: [email protected] - +41 44 724 8573 -
http://www.zurich.ibm.com/~hud/
> _______________________________________________
> Opensim-dev mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
