To Sean,<br>This is a little complecated to explain (, for me :$). and sorry for I did not mention it.<br>About the current flow:<br>>With the user server storing asset and<br>
>inventory ids, the client is sent a wearables packet, which is just a<br>
>bunch of UUIDs. The client then goes and fetches the assets from the<br>
>asset servers.<br>what you said is right, but this causes 2 problems:<br>
1. the same as what you said the "ruth time". During the login process, there is a short time that an avatar will be displayed with default appearance.<br>this is not serious, but -><br>
2. After going into another region, the avatar will be seen in default appearance(visualparams are all 100) from other clients' screen.<br>
The detailed information can also be found at<br><a href="http://opensimulator.org/mantis/view.php?id=1019" target="_blank">http://opensimulator.org/mantis/view.php?id=1019</a><br>1019's attachment gives a working but not good solution. (at least fetching asset data should be Asynchronous)<br>
<br>That problem is because RegionServer itself has no ability to get the visualparams, (currently it only gets 13x2 UUIDs<br>and waits for client to request the visualparams back)<br>So I am thinking in "Scene.GetAvatarAppearance"(r4690 Scene.cs Line:1798).<br>
We can<br>1. get wearables UUIDs(13x2), and then<br>2. foreach (UUIDs) { get actual assetdata(for visualparams) }.<br>Of cause, "2" is the task that "AssetCache" should do.<br>For "1", I think to consider in grid mode, "wearables UUIDs" should have an optional chance to be fetched from an "External Service",<br>
instead of a LocalModule(AvatarFactoryModule.checkdatabase).<br>So what would be the best of this "External Service" ? I think InventoryServer is better than UserServer.<br>The reasons are:<br>1. UserServer should be concertrated on Authentication.<br>
2. InventoryServer is good at serving (User tied up) UUIDs.<br>That is why I think "GetUserAppearance" should be put in InventoryServer.<br><br>regards,<br>lulurun<br><br><div class="gmail_quote">2008/5/14 Sean Dague <<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>>:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div>On Wed, May 14, 2008 at 03:48:08PM +0900, liu xiaolu wrote:<br>
> Hi, everyone,<br>
> I am planing to implement "AssetPortability" in OpenSim,<br>
> The basic idea is to let RegionServer get assets from a<br>
> dynamic(user specified) AssetServerURL.<br>
><br>
> Very thankful for someone added "asseturl" and "inventoryurl"<br>
> to the userprofile structure and the "Users" table.<br>
> (though I do not know exactly what it was he did)<br>
><br>
> Recently, I found there is a stub "GetUserAppearance" in "IUserService".<br>
> This is a little different from what I am thinking, so here I would like to<br>
> share my plan for the "appearance portability" and have a discussion<br>
> with you.<br>
><br>
> # Preparation<br>
> 1. User stores "wearables" in "inventoryserver"<br>
> 2. User stores actual "assetdata" in "assetserver"<br>
> 3. User tells its "asset/inventory url" to "userserver"<br>
> (by user registration or someway like openid)<br>
><br>
> # Login<br>
> At <a href="http://openugai.sourceforge.net/?page=openasset_proposal" target="_blank">http://openugai.sourceforge.net/?page=openasset_proposal</a><br>
> there are 2 possible patterns,<br>
> "Implemetation 1" is following current opensim - "GetUserAppearance" in<br>
> "UserServive".<br>
> "Implemetation 2" is my proposal.<br>
><br>
> * Implemetation 1<br>
> 1. "UserServer" acts as a agent, when "GetUserAppearance" called,<br>
> 2. "UserServer" gets "wearables" from "inventoryserver"<br>
> 3. "UserServer" gets "assetdata" foreach "wearables" UUID.<br>
> 4. "UserServer" returns appearance to RegionServer(OGS1UserServices)<br>
<br>
</div></div>Actually, you have this flow wrong.<br>
<br>
1. Client -> Sim -> User Server (Get My Appearance)<br>
2. User Server -> Sim -> Client (Appearance Packet - lots of UUIDs)<br>
3. Client -> Sim -> Asset Server (foreach wearable get asset)<br>
4. Client -> Sim -> Inventory Server (foreach wearable get inventory)<br>
<br>
If you look a little deeper on the GetUserAppearance data structures<br>
you'll see that only UUIDs are flying around. There will probably be a<br>
caching of visual params as well, as it will make your ruth time when<br>
you first log in smaller.<br>
<div><br>
> * Implemetation 2<br>
> "GetUserAppearance" is not in "UserServer", it should be a module or<br>
> something<br>
> independent. There is<br>
> * "OGS1InventoryServices" incharge of communicating with "InventoryServer".<br>
> * "AssetCache" gets "assetdata" from "AssetServer".<br>
> I think we can use the 2 existing components to "GetUserAppearance".<br>
><br>
> Why I prefer "Implementation 2" ?<br>
> 1. Just as UserServer does not provide "Inventory" information, UesrServer<br>
> also should NOT<br>
> provide appearance information.<br>
> (UserServer should be concentrated on providing basic user information and<br>
> the authentication.)<br>
> 2. If UserServer have to fetch Complete "Appearance", UserServer must know<br>
> about AssetServerUrl,<br>
> and something like "AssetCache" must be implemented inside UserServer. This<br>
> makes UserServer<br>
> become less indenpendent.<br>
<br>
</div>That's actually not true. With the user server storing asset and<br>
inventory ids, the client is sent a wearables packet, which is just a<br>
bunch of UUIDs. The client then goes and fetches the assets from the<br>
asset servers.<br>
<div><br>
> 3. "Appearance" can be thought as "a special inventory folder called<br>
> 'wearables' ".<br>
> (InventoryServer is born to do such things)<br>
<br>
</div>I think that mapping "special cases" onto existing services is trouble<br>
waiting to happen.<br>
<br>
-Sean<br>
<br>
--<br>
__________________________________________________________________<br>
<br>
Sean Dague Mid-Hudson Valley<br>
sean at dague dot net Linux Users Group<br>
<a href="http://dague.net" target="_blank">http://dague.net</a> <a href="http://mhvlug.org" target="_blank">http://mhvlug.org</a><br>
<br>
There is no silver bullet. Plus, werewolves make better neighbors<br>
than zombies, and they tend to keep the vampire population down.<br>
__________________________________________________________________<br>
<br>-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.6 (GNU/Linux)<br>
<br>
iD8DBQFIKuARSamXem9TdyYRAr/pAJ9l1mnEnv7UE7Ne0vADuWdQcCn3ugCdGtbb<br>
ONUSNbCLV3fl+ITqL/ogqR8=<br>
=hhze<br>
-----END PGP SIGNATURE-----<br>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">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></blockquote></div><br><br clear="all"><br>-- <br>Liu Xiaolu