Sean Dague wrote: > Justin Clark-Casey wrote: >> Sean Dague wrote: >>> 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. >>> Ah, but the problem is then those all need to release at the same time. >>> One of the reasons to get us into seperate dlls per module is so that >>> the IRC module could be updated and distributed without pushing out the >>> rest of the dll. >> I would actually argue that in this particular case the IRC module is not a >> core module and should be in the forge. > > But that's really saying 2 things. It should be a seperate dll, and it > should be in a seperate source tree. I'm personally not a fan of doing > both of those things at once, because they are seperate things, and it's > easy to forget that.
This is the case if we have a separate assembly for all modules, but if one has a single dll for all core modules then they really aren't separate things. If one finds oneself wanting to update a single module that doesn't provide functionality that almost everybody will use (such as irc), then that module is not core and should be in its own assembly. And non-core modules in their own assemblies shouldn't really be shipped with core OpenSim in the long term - they should be in the forge or hosted elsewhere. > >>> It would mean that we would easily be able to replace implementations >>> for various core modules without needing to touch the rest. For >>> instance, when diva started to tackle the world map issue, she not only >>> had to build her own world map, but to change the one in the core to not >>> load. Had we been under this model, she wouldn't have needed to do that. >> This would still mean that people would have to move the dll being included >> in core so that it was no longer loaded by >> the system. To me, this seems no less of a task than having a configurable >> list of modules that are loaded. Having to >> move dlls also means that it isn't easy to pass configuration files around - >> instead you have to give instructions or >> scripts for moving around modules in the filesystem. > > This comes back to the addins question. Having seen this work pretty > well with gnome-do, I think that gets addressed seperately, including > the ability to notify you of new upstream modules and download them. Yes, there may well be some interaction here with how mono.addins wants to work. > >>> Don't fear the projects, more projects don't hurt you. :) >> But in this case they do, in terms of cluttering up the solution with lots >> and lots of projects that are all used anyway >> in almost all OpenSim installations and possible in terms of increasing >> build times (I admit that I may be paranoid on >> this point and there might be ways to fix this via nant changes). It will >> also increase the effort required for >> refactoring existing code into modules, since creating a new project takes >> more time. > > So we should put all the database drivers into a single dll? As a Linux > user I'm pained far more by filesystem cluster and mismatch of classname > to .cs file, or dll to directory. I'm not advocating it, but why not if they're all core supported databases? One reason is that they all contain modules which implement the same set of interfaces, so one has to choose between them. At the moment one of the only way we have to do this is by specifying dlls in OpenSim.ini (the other way is having the modules enable/disable depending on passed in config, which is nasty). If there were another way to specify enable/disable then one could put them all in a single dll. One can go the other way and say that why shouldn't we modularize more and put each individual database service (asset, inventory, etc.) into its own module, so that we end up with 21 of them (not counting nhibernate stuff)? After all, people might want to host different services on different 'databases' (e.g. assets as files in a filesystem, user data in LDAP and inventory data in MySQL). You still end up with the issue of how to selectively enable/disable stuff whether you put them in separate dlls or all in one. > > We've already decided that seperation and organization is needed, look > at all the structure in the OpenSim/Region/Environment/Modules directory > tree. > > That being said, this isn't an all or nothing approach. I'd say step > one, lets get the modules into a seperate dll (like diva suggested). > Then we can experiment with some level break up and see if it does cause > the end of the world. :) If so, we can quickly go back. I agree with what other people have said - these would be better off as a separate dll. And by all means experiment once this is done, but I would really not want to see us slide into something that more people have expressed concern about than support for, at least not without seeing some more convincing arguments/evidence that the benefits outweigh the cons (or that the cons are unfounded). -- justincc Justin Clark-Casey http://justincc.wordpress.com _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
