Justin Clark-Casey wrote: > > +1 Indeed, I would love to have a way to get modules/connectors/whatever > that > implement interfaces such as IInventoryService and IAssetService without > having > to go through the scene. It seems perverse that code which has little to do > with the region (apart from some communication with the client in the IAR > case) > has to request modules via the scene. > > Ideally, I guess the IAR code would be split into two separate modules, one > large one which actually does the archiving/dearching work, and a small one > which does scene specific stuff such as tell a logged in avatar about newly > loaded folders and items. But then one hits issues of co-ordinating this > module > loading and intermodule communication. > > Splitting the archiving/dearchiving code just into a separate dll is another > option but this could be an unwelcome step backwards in terms of modularity. > > The archiving utility should not be a region module -- region modules are addons that need to access scenes, and the archiving utility doesn't need that. The only thing it needs are references to an IAssetService and IInventoryService.
The command line you wrote, save/load oar, needs access to scene and uses the archiving utility. As such, it needs a [very thin] region module, the one you already have for all the checks and balances, and then should use the general archiving utility. I think the archiving utility should be part of a dll called OpenSim.Archives or, if you want to gather more goodies in a larger dll, OpenSim.Utilities. The point is that lots of other tools that have nothing to do with scenes (hence, nothing to do with region modules) will make use the the archiving utility -- i.e. getting a listing of a user's inventory and packing/unpacking it, along with the corresponding assets, into/from a ball. That is 100% generic, has nothing to do with scenes. _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
