<div>I like the idea of grid independent storage providers (assets and inventories). It is in analogy with open id providers which are application independent identity providers. The challenge with both is that the UUID should always be accompanied by the provider url unless we have a way to resolve provider URL from asset UUID. In other words if Frank will have texture asset on his avatar with given UUID it does not get me anywhere unless I have a way to find out from which URL I can actually download that asset. You can hide this from the viewer program and implement it in region services for example but ultimately you will still face the same problem. If we want simple engineering solution which works in all situations we should figure out how we will solve mapping from asset UUID to provider service URL. Possible solutions:</div>
<div> </div>
<div>1) Use keys which consists of UUID and asset provider URL instead of just UUID's (not very practical when you store the key to database)<br>2) Have distributed registry with maps UUIDs and provider URLs. This might be even theoretically impossible as they amount of keys in the distributed registry would be same as all the assets in the internet. Could this be resolved by allocating UUIDs to different nodes based on somekind of UUID hash value?</div>
<div>3) Try to hard wire asset access to correct repository behind the scenes. In other words in HG region all avatars would notify the region which is their asset provider and region will broker the asset calls to correct asset provider. Client in turn assumes that each region may have separate asset server and queries assets separately from each region. This is not very clean solution and can result in quite complex overall system.</div>
<div> </div>
<div>Number 2 would be good for enforcing uniqueness of UUID's so that it is not possible to manually copy an asset and steal the identity by using the same UUID. So this registry could be used to also store ownerhship rights for UUIDs.</div>
<div> </div>
<div>Work name: Distributed Identity Ownerhship and Provider Registry</div>
<div> </div>
<div>best regards,</div>
<div>Tommi Laukkanen<br></div>
<div class="gmail_quote">On Sun, Feb 8, 2009 at 11:21 PM, Paul Fishwick <span dir="ltr"><<a href="mailto:fishwick@cise.ufl.edu">fishwick@cise.ufl.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">On the observation that most multi-player games have asset stored<br>client-side,<br>thus allowing huge and feature-rich worlds, it would be nice to have an<br>
option ("private assets", "fixed assets" perhaps indicated by land<br>parcel ?) that required people who wanted to take advantage of<br>interacting there to first download all assets prior to launching<br>
the viewer. Having both ends of the spectrum (at one end, all<br>startup assets are private and non-dynamically shared and at the other<br>end, all assets are dynamically loaded to each connecting client)<br>would provide more flexibility and some detailed spaces.<br>
<br>-p<br>
<div>
<div></div>
<div class="Wj3C7c"><br>Frank Nichols wrote:<br>> I like the idea of shifting responsibility for user storage costs closer<br>> to the user. Region maybe a good place to do this.<br>><br>> Frank<br>><br>> Charles Krinke wrote:<br>
><br>>> We have been studying the assets table on OSGrid as it heads toward<br>>> the "disk full" stage and I have a couple of observations and am<br>>> heading towards a suggestion. Maybe this is already accounted for in<br>
>> the "Cable Beach" project, at which point, this will only indicate<br>>> that I did not read all the exchanges carefully enough.<br>>><br>>> It appears to me that we are storing on the MySQL data store at the<br>
>> assetServer on a grid every edit of every script, terrainImage and<br>>> clothingItem amongst other things. So, my first observation is that we<br>>> appear to be storing all the older, obsolete items that can no longer<br>
>> be accessed.<br>>><br>>> Additionally, it appears to me that we are also storing things that<br>>> could arguably be stored on the regions datastore, such as the<br>>> terrainImage.<br>>><br>
>> Now, to the beginnings of a suggestion. It seems to me that each<br>>> avatar will have a "home" region. And that perhaps that is the place<br>>> to store the items in an avatars inventory. Things like scripts,<br>
>> notecards, textures and the like.<br>>><br>>> At that point, the assetServer on a grid could be used to store only<br>>> pointers (or URL's) to each avatars inventory on his or her home region.<br>
>><br>>> So, by doing that, we start shifting the ever increasing disk storage<br>>> requirements of a grid back to the regions distributed around the<br>>> internet.<br>>><br>>> Again, perhaps Cable Beach is already doing this, and if so, this is<br>
>> great. If not, I put out these ideas and duck as the tomatoes start<br>>> flying.<br>>><br>>> Charles<br>>> ------------------------------------------------------------------------<br>>><br>
>> _______________________________________________<br>>> Opensim-dev mailing list<br>>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
>><br>>><br>><br>> _______________________________________________<br>> Opensim-dev mailing list<br>> <a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>> <a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
><br>><br><br><br></div></div>--<br>Paul Fishwick, PhD<br>Professor and Director, Digital Arts and Sciences Programs<br>University of Florida<br>Computer & Information Science and Eng. Dept.<br>Bldg. CSE, Room 301<br>
P.O. Box 116120<br>Gainesville, FL 32611<br>Email: <a href="mailto:fishwick@cise.ufl.edu">fishwick@cise.ufl.edu</a><br>Phone: (352) 392-1414<br>Fax: (352) 392-1220<br>Web: <a href="http://www.cise.ufl.edu/~fishwick" target="_blank">http://www.cise.ufl.edu/~fishwick</a><br>
<div>
<div></div>
<div class="Wj3C7c"><br>_______________________________________________<br>Opensim-dev mailing list<br><a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br><a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
</div></div></blockquote></div><br>