A little busy today, and when I was back to the mailing list, there seems to already have a conclusion.<br>to bring new features in seems to be a big challenge for me :)<br>I understand the reason that big changes(especially about architecture) are not easy to be accepted.<br>
<br>however, as I see the "persistent asset region cache", it sounds like similar to my "RegionAsset" table.<br>Even it does bring lots of advantages that satisfies most of my concerns,<br><br>But still I want to state my points and ask some questions:<br>
1. To subdivide the assets table is for *management* of assets. Growing assets is not a disk space issue,<br>   nor a performance issue. we have to develop better methods to handle the "PROBLEMS" brought by large,<br>
   unmanaged assets.<br>   here, "PROBLEMS" points to "region portability", "asset garbage collection", "grid admin convenience".<br>2. My proposal is focused on "storage", not "service" or "structure". in the most simple case, all assets<br>
   can be still served by one central server, but inside the central server they should not be put together.<br>   To worry about "prims crossing", "child agent" is good but a little far from the basic.<br>
3. In secondlife, "User HAVE TO own assets" because during the creation, the only way you can do is to<br>   first upload asset file, and then drag it from inventory to a prim, but OpenSim region owner completely<br>
   controls DB, region assets can be imported directly. assets on prims can be only referenced by prims.<br><br>Questions:<br>1. Do you think assets management (at least for grid service) is a serious issue ?<br>2. If a prim P is *originally* a part of a building on region R, Do you think P is owned by R ?<br>
 2.1 If asset A *only* referenced by P, Do you think it is good to say A is owned by P, and A is owned by R ?<br> 2.2 Do you think it is not necessary for A exists in an User's inventory ?<br>3. If you answer yes to "2.*", Do you think it is *strange* that, A and P are both owned by R, but P is saved<br>
   in a R exclusively used table, but A is saved in a shared table ?<br>4. When you talk about "prim crossing", "child agent", "ID space management", Have you ever thought is<br>   there any difference between P and A in that 3 situations ?<br>
   (<br>     brief points of this question:<br>     * for "prim crossing", if P can go across, can't A use the same method ?<br>     * for "child agent", if P can be got from neighbor, can't A be fetched from neighbor's asset table (or service) ?<br>
     * for "ID space management", I think here "ID" means assetid, then What is primid space management ?<br>       Do you think P and A are under the same scope ?<br>     * Back to question 3, Why P is alowed to be stored separatly, but A is not ?<br>
   )<br><br>Anyway, once more, I understand the reason that big changes(especially about architecture) are not easy to<br>be accepted, and there are many uncertains in my original proposal.<br>What do you think if I lowered my proposal level as:<br>
the most simple case, all assets can be still served by one central server, but inside the central server<br>they should not be well managed.<br>in this case, really nothing changes, except inside the current assetserver.<br>
<br><br>Lulurun,<br>regards<br><br>