[Opensim-dev] Designing with reusability in mind

[Justin Clark-Casey]

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.

-- 
Justin Clark-Casey (justincc)
http://justincc.org
http://twitter.com/justincc