Um. Having immutable assets do bring a number of optimization shortcuts. I'm not saying it's all good - merely that it's not all bad.
The OpenSim solution, as always, is to address each case by itself, and to make divergence optional. So, maybe region map textures should be overwriteable. Maybe some scripts should be overwriteable as well, maybe only on some type of scripts. Maybe we should have a table enumerating what assetIds now point to newer assetIds. Maybe the real problem is that we are talking about 'assets' and 'textures' instead of 'prim face textures', 'sculptie maps', 'photos', 'region map images', 'script sources', 'sounds', 'prims in inventory', 'notecards', 'animations' - my point being that we can probably implement various configurable strategies for each of them, linden viewer or no linden viewer. Best regards, Stefan Andersson Tribal Media AB > Date: Wed, 18 Feb 2009 16:37:12 +0100 > From: dirk.kra...@pixelpark.com > To: opensim-dev@lists.berlios.de > Subject: Re: [Opensim-dev] oddities with asset storage > > ... > > >> This would mean that any grid runs into a severe problem over time. > > >> Yep :). On a standalone one could implement some cleanup scheme > which checks everything to see > >> if an asset is still referenced, and deletes that asset if it is not. > >> In grid mode this is a much more difficult problem since references > are scattered across many different > >> regions servers. The situation is even worse if you are running a > grid where not all of them are > >> guaranteed to be connected. > > But isn't that ... horrible? (in lack of a better/worse word.) > > As I said yesterday, IMHO there is no real need to think about > optimizations when you have > a serious blocker like this. I would even go so far that this is a major > roadblock for grid based technologies per se. (grid as in Rosedale's > 'Happily now, Second Life has been proven to exist. If we disappeared > tomorrow, the grid would be rebuilt by you.') > > I take it the bad news is that any proposed solution to this breaks SL > compatibility? > > Maybe now would be a good time to take a step away from it. > > _______________________________________________ > 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
