Why not push the first time a file is added; then add some sort of marker 'assets from IAR with filesize X are already imported'.
Frankly though - even on a big grid the time to import probably isn't that significant. Adam > -----Original Message----- > From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > boun...@lists.berlios.de] On Behalf Of Melanie > Sent: Wednesday, 9 December 2009 4:34 PM > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] Designing with reusability in mind > > 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: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev- > >> boun...@lists.berlios.de] On Behalf Of d...@metaverseink.com > >> Sent: Wednesday, 9 December 2009 10:39 AM > >> To: opensim-dev@lists.berlios.de > >> 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 > >> Opensim-dev@lists.berlios.de > >> https://lists.berlios.de/mailman/listinfo/opensim-dev > > _______________________________________________ > > Opensim-dev mailing list > > Opensim-dev@lists.berlios.de > > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
