[Opensim-dev] Designing with reusability in mind

[Justin Clark-Casey]

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

Sure.  But if there's a separate DLL that doesn't perform runtime checks then it 
would become the responsibility of the calling code to actually perform those 
checks.  Evolution in this direction is inevitable but, as I'm sure you know, 
relying on calling code to perform checks may make the issues with our current 
architecture more obvious.

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

Strictly speaking, there's some messy cross calling to some code in the OAR 
modules.  I can't remember if these are in areas tied to the scene or otherwise. 
  If otherwise, this could should be refactored anyway and a separate DLL would 
be a prime candidate for it.

In fact, you probably want to combine any separate DLL with the code already in 
OpenSim.Framework.Serialization.dll.  So there kind of already is a separate DLL 
(my excuse it that I didn't create it, though I didn't object :).

> 
> 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.
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> 


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