[Opensim-dev] Designing with reusability in mind

[Justin Clark-Casey]

diva at metaverseink.com wrote:
> In the same vein as Teravus' message about designing with 
> instrumentation in mind...
> 
> I would like to ask for us to design with reusability in mind. Let's get 
> out of the model that we are developing an application, and always think 
> that we are developing components that can be used both for putting 
> together an application that looks like SL, and for other applications 
> as well.
> 
> Case in point: in the sequence of the conversation about free IARs, 
> OARs, etc., I have been putting together a package with freebies. I 
> thought about releasing it as an IAR, like everyone else is doing, but 
> this has a problem: it requires operator access to the server -- not all 
> users can take advantage of this free content.
> 
> Solution: let's use the underused OpenSim Library and add more stuff in 
> there. No one has changed that part of OpenSim for ages! There's a good 
> reason for it: adding content to it manually is a huge PITA and 
> extremely error-prone. So, idea: let's take any IAR and write an 
> external tool that converts it into the OpenSim Library format. That way 
> different operators can provide different libraries very easily: just 
> take your favorite IAR and dump it into your OpenSim Library, therefore 
> making it available to all of your users.
> 
> This sounds easy enough. Justin has the code for unarchiving IARs... 
> except that it's all tangled up with Scenes. :-/
> 
> The rule of thumb for reusability in the context of OpenSim is very 
> easy: the region modules that come in OpenSim.Region.CoreModules.dll 
> should be as thin as possible. They should only have enough meat to 
> bridge between Scenes and whatever it is those modules actually do. 
> "Whatever it is they do", for the most part, is relatively generic and 
> should be factored out into their own dll, so that it can be reused from 
> elsewhere that has nothing to do with scenes. Example: all the service 
> connectors now can be reused out of the box by other tools to access 
> remote OpenSim servers. (OpenSim.Service.Connectors.dll)
> 
> Counter-Example: inventory archiving/dearchiving. From looking at that 
> code, the only reason why the actual worker code needs the Scene object 
> is to be able to get to IInventoryService and IAssetService. So... it 
> should get those instead of Scene, and it should be factored out from 
> Region.CoreModules, because inventory archiving/dearchiving is a lot 
> more generic than a Scene utility.
> 
> That way I could write this tool that I want in 4 hours reusing Justin's 
> code as a dll, instead of having to copy-and-paste Justin's code and 
> purge it from all references to Scene. I would simply need to provide my 
> own implementation of IInventoryService and IAssetService that would 
> write things in bin/assets and bin/inventory instead of sending them to 
> a server.
> 
> The general request is this: let's not hide useful code under 
> OpenSim.Region.*, which are components that only make sense for the live 
> VW server. There's so many more tools/applications that can be done 
> around it! -- let's not hide good code under there, where it can never 
> be reused.

+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.

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