IARs also contain the assets, which would be stored to the asset server again and again. On large servers, this could take ages. So, I don't think IAR is a good idea, unless it's stipulated that the IAR must have been made on the same server/grid, and that any assets contained inside are ignored for the purpose of building the library, and are assumed to be present in the asset server.
Melanie Frisby, Adam wrote: > Re: Library > > My thought was to have a directory where we can save .iar files - and the > library is built from all the IARs in that directory at time the inventory > server is started. > > Adam > >> -----Original Message----- >> From: [email protected] [mailto:opensim-dev- >> [email protected]] On Behalf Of [email protected] >> Sent: Wednesday, 9 December 2009 10:39 AM >> To: [email protected] >> Subject: [Opensim-dev] Designing with reusability in mind >> >> 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. >> >> Crista / Diva >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
