Glad you asked :-).

I would do a mixture of the following (and admit that I didn't think it all 
through to the very end).

- introduce grid wide, region wide and personal (user) asset domains
- introduce quotas for these
- allow clones ('byref') assets, and copies that go into one of the domains, 
resp.

I then would expect to have grid wide assets that are 'always on', region wide 
assets that only are important when the region is connected, and personal 
assets that are only visible when the user is online (could even be an FTP 
server behind a cable beach server).

It boils down to: if someone treasures something, she better keeps it in her 
treasure chest, in her responsibility (and maintenance cost).


-----Ursprüngliche Nachricht-----
Von: opensim-dev-boun...@lists.berlios.de 
[mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Dr Scofield
Gesendet: Mittwoch, 18. Februar 2009 17:41
An: opensim-dev@lists.berlios.de
Betreff: Re: [Opensim-dev] oddities with asset storage

Dirk Krause wrote:
> ...
[...]
> 
> 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.

so, what do you supposed should be done? ride OpenSim on web route 404? lots of
dangling references?

i supposed on a standalone system you could do ref counting or bidirectional
refs/links --- that however is not a very scalable solution for a grid with
sporadically connected grid components.

one avatar's garbage is another avatar's treasure...

        DrS/dirk


-- 
dr dirk husemann ---- virtual worlds research ---- ibm zurich research lab
SL: dr scofield ---- drscofi...@xyzzyxyzzy.net ---- http://xyzzyxyzzy.net/
RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/
_______________________________________________
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

Reply via email to