This isn't about forking opensim, its about making opensim flexible.<br><br>We don't want one way of things working. We don't want every module to have to use Mono.addins via a config.xml or whatever. If a application wants to set a group of modules from the code that don't get loaded through some plugin system, then it should be able to. The current plugin system allows this. We should make changes that make things less flexible. Yes the current plugin system is far from ideal, but neither is hardcoding a set way of it working.<br><br>Btw, I think the little dig with the fork comment was out of line. We are not forking anything. We are creating applications based on opensim. Which was always and is the purpose of opensim. Its not meant to be a big monolithic project that just is a SL clone. Although it is aiming more in that direction lately.<br><br>If OpenSim doesn't support people taking it and using it as a base for other applications, and them modifying the parts they
need to. And is now just meant to be a single application that functions as a SL clone Then its no longer anything like the project I started and thats a very sorry state for it to end up in. <br><br><b><i>Sean Dague <sean@dague.net></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> On Wed, Jun 25, 2008 at 08:14:19AM +0200, Stefan Andersson wrote:<br>> > > As Sean says, it would be nice if we could use Mono.Addins facilities > > directly.> > Until I have a reason to do otherwise, I'd like to keep the wrapper as> thin as possible. There should be no reason why you couldn't use> Mono.Addins directly.<br>> One very good reason is simply this: It's out of our control.<br>><br>> Another very good reason: To be able to 'snip' off the reference chain<br>> when coding for aux scenarios (like customized solutions, tools and<br>> test cases)<br>> <br>>
A third reason: To be able to cater for application- specific cases<br>> where mono addins for some reason (behavior requirements, licensing,<br>> signing) is deemed unfit.<br>><br>> All these points should be considered when looking at bringing in<br>> third party libraries. And, it goes even for mono standard libraries,<br>> if those aren't a part of the .NET framework.<br><br>As per usual, I fall on the other side of this point. OpenSim is an<br>open source project, and as such shouldn't reinvent everything itself.<br>Building on the good works of others is critical to rapid innovation in<br>the open. If Addins has a short fall, we're better off contributing to<br>it than replacing it.<br> <br>> Tribal is one of those developers that will gain very little from mono<br>> addins, customizes plugin loading on a daily basis, and risk a lot of<br>> frustration from it being wired into the core.<br><br>Anyone developing lots of things outside the
community and not<br>contributing them back to the core runs the risk of having their work<br>obsoleted by changes in the core. This is why forking code is always<br>cheap in the short run and expensive in the long run. :)<br><br> -Sean<br><br>-- <br>__________________________________________________________________<br><br>Sean Dague Mid-Hudson Valley<br>sean at dague dot net Linux Users Group<br>http://dague.net http://mhvlug.org<br><br>There is no silver bullet. Plus, werewolves make better neighbors<br>than zombies, and they tend to keep the vampire population down.<br>__________________________________________________________________<br>_______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></blockquote><br><p>
<hr size=1>
Sent from <a
href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52418/*http://uk.docs.yahoo.com/nowyoucan.html" target=_blank>Yahoo! Mail</a>.
<br>
A Smarter Email.