[Opensim-dev] Designing with reusability in mind

[diva at metaverseink.com]

Unless I'm missing something that VC#-search doesn't show me...
The run-time checks are done by the region module that you already have. 
That module is fine for implementing the commands save/load oar. The 
necessary checks in those commands are done before the archiving utility 
is invoked. The only thing the archiving utility needs are references to 
an IAssetService and an IInventoryService, it doesn't do any more checks 
related to scenes.

And to be very clear, by "archiving utility" I mean 
InventoryArchiveReadRequest, InventoryArchiveWriteRequest, and 
InventoryArchiveUtils -- that's where you have all the goodies.

InventoryArchiverModule is the necessary region module that makes 
archiving/dearchiving available in the VW server console in the form of 
two command line commands. That should stay exactly where it is.

Justin Clark-Casey wrote:
> diva at metaverseink.com 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.
>