[email protected] wrote: > 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.
Yes, I do agree with that. There's no real reason to only do [de]archiving within a running region simulator, though you will lose the runtime checks that way. And I'm sure being able to invoke the functionality without requiring a running simulator would be very useful. So I really don't have a strong objection to putting code into a separate DLL, though resolving the interface links may be difficult without effectively recreating the module mechanism or doing something messy with ini configuration. The only thing I would want to see (of course) is that the existing functionality doesn't become more difficult to use, that any new functionality is documented and that the existing oar/iar unit tests continue to be present and passing for every panda build. -- Justin Clark-Casey (justincc) http://justincc.org http://twitter.com/justincc _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
