[Opensim-dev] Proposal to subdivide the assets table

[liu xiaolu]

A little busy today, and when I was back to the mailing list, there seems to
already have a conclusion.
to bring new features in seems to be a big challenge for me :)
I understand the reason that big changes(especially about architecture) are
not easy to be accepted.

however, as I see the "persistent asset region cache", it sounds like
similar to my "RegionAsset" table.
Even it does bring lots of advantages that satisfies most of my concerns,

But still I want to state my points and ask some questions:
1. To subdivide the assets table is for *management* of assets. Growing
assets is not a disk space issue,
   nor a performance issue. we have to develop better methods to handle the
"PROBLEMS" brought by large,
   unmanaged assets.
   here, "PROBLEMS" points to "region portability", "asset garbage
collection", "grid admin convenience".
2. My proposal is focused on "storage", not "service" or "structure". in the
most simple case, all assets
   can be still served by one central server, but inside the central server
they should not be put together.
   To worry about "prims crossing", "child agent" is good but a little far
from the basic.
3. In secondlife, "User HAVE TO own assets" because during the creation, the
only way you can do is to
   first upload asset file, and then drag it from inventory to a prim, but
OpenSim region owner completely
   controls DB, region assets can be imported directly. assets on prims can
be only referenced by prims.

Questions:
1. Do you think assets management (at least for grid service) is a serious
issue ?
2. If a prim P is *originally* a part of a building on region R, Do you
think P is owned by R ?
 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 ?
 2.2 Do you think it is not necessary for A exists in an User's inventory ?
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
   in a R exclusively used table, but A is saved in a shared table ?
4. When you talk about "prim crossing", "child agent", "ID space
management", Have you ever thought is
   there any difference between P and A in that 3 situations ?
   (
     brief points of this question:
     * for "prim crossing", if P can go across, can't A use the same method
?
     * for "child agent", if P can be got from neighbor, can't A be fetched
from neighbor's asset table (or service) ?
     * for "ID space management", I think here "ID" means assetid, then What
is primid space management ?
       Do you think P and A are under the same scope ?
     * Back to question 3, Why P is alowed to be stored separatly, but A is
not ?
   )

Anyway, once more, I understand the reason that big changes(especially about
architecture) are not easy to
be accepted, and there are many uncertains in my original proposal.
What do you think if I lowered my proposal level as:
the most simple case, all assets can be still served by one central server,
but inside the central server
they should not be well managed.
in this case, really nothing changes, except inside the current assetserver.


Lulurun,
regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080628/87bef8a9/attachment-0001.html>