Thank you for the "Cons", that makes my mind more clear about the subdividing proposal,<br>
Maybe my proposal about "how to subdivide" is not good or not completed or wrong.<br>but I think there are *necessities* of subdividing assets table as I wrote in this mail.<br>This mail is not going to talk about "HOW", I will send another mail later, to discuss about<br>
my throughts on your comments.<br><br>There are 2 basic reasons of the subdividing:<br>1. No matter to use centralized or distributed assetservers, due to the *maintenancibility* of the asset data,<br> even my proposal is wrong, we have to consider a way to store assets but not just simply put assets<br>
all together, assets have to be well managed.<br> assets are identified by UUID, but should not be managed (only) by UUID, assets should also be managed<br> by its purpose(for avatar, for region) and by its location(for which region).<br>
2. Since regionserver maybe not only owned by gridservice, but also owned by individual region owners, Making<br> regionserver more indenpendent increases regionserver(sim)'s *flexibility* and *portability*. (regionserver is not<br>
suppose to be tied up with only one gridservice)<br><br>I think to be compared to secondlife(even someone do not like to do so), OpenSim's main advantage is "OPEN",<br>this is also the reason I feel happy to be involved in the project :)<br>
So we have to care about problems only happened in a *open* world:<br>1. "maintenancibility" is a issue for grid admin, there is a big difference between a close world(secondlife) and<br> a opengrid(OSGrid).<br>
in secondlife, since all of the data is kept by linden, no matter
easy or difficult, they can find out "all textures<br> of a region", if a region resigned or want to be moved under another assetservice, linden can delete all of its<br> assets without disturbing other regions.<br>
But in OSGrid, individual regionservers are open to register, so once the assetservice is started, it can not<br> be stopped.(however, it a free service ...) and the number of assets grows forever.<br>2. "portability" is a issue mainly for region owner. in secondlife there is no "real" region owner, but in OSGrid,<br>
when a region owner want to switch to anther grid service, they can not get thier assets back(easily).<br> And originally, prims are supposed to be closly with its assets(texture), It is OK to store them separatly, but<br>
prims are well managed by "regionUUID", while assets are mixed together.<br>
<br>Lulurun,<br>regards<br><br><br><div class="gmail_quote">2008/6/27 Melanie <<a href="mailto:melanie@t-data.com">melanie@t-data.com</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
I'm sorry, but I don't see this being possible in quite the way<br>
described. Actually, there are quite a few good points there, though.<br>
<br>
Pros:<br>
- Decrease network traffic<br>
- Decrease dependency on external servers<br>
- Increase reliability<br>
- Increase responsiveness<br>
- Save space on asset server<br>
<br>
Cons:<br>
- Prim crossings are much more difficult<br>
- ID space management is near impossible<br>
- Asset transfer between sims becomes a large issue<br>
- UUID referencing in scripts is no longer possible<br>
<br>
Well, to make a long story short: Regions don't own assets. Regions<br>
use assets. Users own assets.<br>
<br>
So, a centralized asset storage is certainly needed, tied into the<br>
concepts around asset portability, possibly several centralized<br>
asset servers.<br>
<br>
But assets are immutable and a region is a finite space. This makes<br>
it an ideal situation for a persistent cache. While we cannot<br>
totally remove centralized asset storage, almost all the above<br>
points can be achieved by locally caching a region's used assets on<br>
disk. This cache can be two-tiered:<br>
<br>
Tier 1: referenced assets, indefinite retention<br>
Tier 2: unreferenced assets, short term retention<br>
<br>
This means, that textures on a prim would be cached locally forever,<br>
but textures that make up the clothing of an avatar passing through<br>
would be purged after a day or so.<br>
For sounds, playing them would re-trigger the retention period, so<br>
that looped sounds will effectively be retained forever as well.<br>
Same goes for any frequently used asset, however, we should probably<br>
not cache object assets.<br>
<br>
The one thing that this doesn't address is the issue of asset server<br>
disk space usage. However, with the proposed approach of hashing and<br>
de-duping, this becomes a much smaller problem already.<br>
<br>
However, because of the ability to reference an asset by it's UUID,<br>
letting a region "own" an asset is still not possible.<br>
<br>
Assume a texture, which I uploaded.<br>
I placed it on a prim, then, later, deleted the uploaded texture<br>
from my inventory.<br>
Technically, one could say that a region now holds the only<br>
reference, and the texture would be owned by that region. It could<br>
be removed from the central server as soon as it is no longer<br>
referenced by any _agent_ inventory links.<br>
<br>
But, now there are three scenarios:<br>
<br>
1) The prim is pushed across a region boundary. The destination<br>
region requests the texture from the asset server and fails. The<br>
prim will turn gray.<br>
<br>
2) The prim has previously been "take"n. A copy exists in egent<br>
inventory, but the list of the resources needed to reconstitute this<br>
"object" is hidden in the asset, actually, multiple asset records.<br>
If the texture has been removed from the central server, rezzing<br>
this object in any region where the texture is not in use will fail.<br>
<br>
3) If i deleted the texture, there is no guarantee that I have also<br>
lost it's UUID. I may have a notecard with all my texture UUIDs and<br>
use them in scripts. Such scripts, taken to other regions, would fail.<br>
<br>
Issue 1 could be addressed by transferring the needed resources<br>
along with the object, however, on a distributed grid like OSGrid,<br>
this can be time-consuming, as home DSL may be involved.<br>
<br>
Issue 3 could be addressed by creating a list of resources needed at<br>
the time of the "take" and making that part of the inventory record.<br>
This would significantly bloat the inventory table, as each prim's<br>
inventory, face textures and all sounds/animations it might play are<br>
listed in the database.<br>
<br>
Issue 3 cannot be reasonably addressed.<br>
<br>
Therefore, caching, which is something I have looked into and am<br>
going to write some code for, is an absolutely viable solution for<br>
many of the raised issues, but weeding the central server's contents<br>
in such a way seems to be impracticable.<br>
<br>
Melanie<br>
<div><div></div><div class="Wj3C7c"><br>
liu xiaolu wrote:<br>
> Hi everyone,<br>
><br>
> my proposal is to subdivide current assets table into 2 tables:<br>
> user_assets : for user owned assets (mainly in inventory, appearance,<br>
> attachment, ...)<br>
> user_asset is used by UGAI servers<br>
> region_assets: for region owned assets, sounds, textures(including sun,<br>
> moon, ...)<br>
> region_asset is used by region servers<br>
><br>
> I wrote the whole, detailed idea at:<br>
> <a href="http://opensimulator.org/wiki/User:Lulurun#proposal_to_subdivide_the_assets_table" target="_blank">http://opensimulator.org/wiki/User:Lulurun#proposal_to_subdivide_the_assets_table</a><br>
> Please have a look at it, here is only a brief introduction.<br>
><br>
> This could bring us many advantages such as:<br>
> 0. increase the dispersity of asset data, clarify the responsibility of<br>
> each server.<br>
> Currently, all of the asset data is stored in assets table, managed by<br>
> assetserver.<br>
> This would cause some problems:<br>
> 1. assets table keeps growing in a fast pace.<br>
> 2. hard to determine which asset is belongs to inactive regions (when<br>
> you want to "clean"<br>
> the assets table).<br>
> 3. assetserver not only serves users' data but also regions' data, if<br>
> something happened to<br>
> assetserver both of avatar and prims will become gray.<br>
> To separate assets table can not only solve these problems, but also<br>
> brings minor benefits<br>
> such like: reduce the responsibility of assetserver, disperse the asset<br>
> requests(especially<br>
> for big grid service), lower the risk of losing data, ...<br>
><br>
> 1. for Data Portability in virtual world<br>
> For grid admin,<br>
> * you can concentrate on managing only user(not region owner) relavent<br>
> information<br>
> like "users, avatarappearance, inventory"<br>
> * it can reduce the vulnerability caused by foreign assets.<br>
> * when a region leaves your grid, you don't have to worry about its<br>
> assets becoming garbage.<br>
> - on the other hand, this also good for region owners.<br>
> For when a user registers their region server with a grid,<br>
> * When you want to switch your sim to a new grid, "prims, primshapes,<br>
> terrain, region_asset"<br>
> are always tied-up together. the only thing you need to do is to edit<br>
> UGAI servers URI in<br>
> your OpenSim.ini<br>
><br>
> For more advantages, please have a look at<br>
> <a href="http://opensimulator.org/wiki/User:Lulurun#Advantages" target="_blank">http://opensimulator.org/wiki/User:Lulurun#Advantages</a><br>
><br>
> If this is a good way to go, not so many changes is needed:<br>
> * UGAI servers would remain as they used to be.<br>
> * VW user won't feel anything different.<br>
> * Of course this should be a option in OpenSim.ini so that we can<br>
> enable/disable/config<br>
> * Just need to add supports for a new table "RegionAssets" with the same<br>
> structure as "assets".<br>
> * AssetClient in RegionServer should be improved to be able to get<br>
> assets from mutilple servers.<br>
><br>
> For more detailed plan of the implementation, please have a look at<br>
> <a href="http://opensimulator.org/wiki/User:Lulurun#Implementation" target="_blank">http://opensimulator.org/wiki/User:Lulurun#Implementation</a><br>
><br>
> Any advice, comment, thought is appreciate.<br>
><br>
> --<br>
> Lulurun<br>
> regards<br>
><br>
><br>
</div></div>> ------------------------------------------------------------------------<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>
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>
</blockquote></div><br><br clear="all"><br>-- <br>Lulurun