[Opensim-dev] Module/Plugin Loading

Thu Jun 26 07:49:11 UTC 2008

> Those attributes are just syntactic sugar. Once you start really using> the features of Mono.Addins you're best of configuring your addins> with the XML file.
That's probably the way to go, yeah.
 > Its also worth nothing that there is nothing in Mono.Addin's XML> config file that replaces anything in OpenSim.ini, nor vice versa.> They are completely orthogonal configuration files which are> unrelated. There is no OpenSim v. Mono.Addins dilemma.
I think that what some of us are worried about is the configuration creep; there's slowly getting more and more ways of configuring various aspects of OpenSim, and each configuration is something more to grok in order to use.

afaik, we have Prebuild, log4net, NHibernate, Nini, the database configuration files, the opensim.ini, various grid inis, some settings are stored in a yap database, the region configs - and now Mono Addins. Each following different syntax and structure.

So, we're starting to get something like what we're trying to solve with unifying the plugin architecture.

At some point, we need to look at unifying our configs. Introducing Nini was a stab at that, but seems to have lost momentum. Personally, I have somewhat lost faith in Nini, as it doesn't really seem to handle hierarchical data on several instances too well.
> > I most likely haven't dug deep enough into mono.addins and there could well> > be a method to do cut out the attributes and not require manifest files. But> > anyway my point is that I believe a implied effect of those requirements is> > that we don't have references to Mono.addins in the core opensim assemblys.> > (OpenSim.Framework.X , etc)> >> > Let me give my opinion on the matter:> > - There is a principle in both good engineering and open source: don't> reinvent the wheel. Plenty of people have written DLL loaders, and I> see no reason presented here why we should roll our own.
As I see it, there is a breaking point where the concrete gain per work of using a third party solution outweighs the concrete gain per work of rolling your own.

I think this discussion is much about what the gain is and what the work is.

If we just want to load dll's on-the-fly, we already have that. Unify it, add loading from ini files, and we have exactly what we need, sleek and simple. It can be solved in three or four classes. No rocket science.

But there has been some suggestions that we could do more with plug-ins, like auto-fetch from repos, version and dependency handling and stuff, and I guess we should discuss THOSE use cases first. Because if we're saying we want THAT - hell yeah, I wouldn't want THAT home-grown.
 > - Mono.Addins provides features that our custom jobbie doesn't. Maybe> those features aren't critical, but given that they come to us> pre-debugged, I fail to see how its a loss to accept them.
Because nothing comes for free. We choose that component, with its set of design choices and idiosyncrasies (all code have theirs)

We get a piece of code that is outside our direct control, so we can't do quick restructuring or addings as we realize we need them.

So, if we only want what we already have (and can do with even less code than we have today) but choose to import a whole framework to do it, it would quite simply be bloat, on several layers.
> - There are two main sources of Addin loaders: Mono and .NET.> Mono.Addins was inherited from SharpDevelop and Eclipse -- a strong> pedigree. The .NET version is new as of 3.5 runtime, and not yet in> Mono. However, given how similar it looks to Mono.Addins, I wouldn't> be surprised if it wasn't lifted to a large degree from Mono.Addins> (which after all is MIT/X11 licensed).> > - So long as mono only supports Mono.Addins, the only cross-platform> thing to do is use Mono.Addins. When Mono support System.Addin, we can> migrate to that.
The bigger the reason to have our own indirection already in place.

Yay!

/Stefan

PS I use the term 'indirection' a lot...
http://en.wikipedia.org/wiki/Indirection
"Any programming problem can be solved by adding a level of indirection." (Butler Lampson)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080626/3e34fc99/attachment-0001.html>