[Opensim-dev] Where should we put GetUserAppearance ?

Sean Dague sean at dague.net
Wed May 14 12:50:25 UTC 2008


On Wed, May 14, 2008 at 03:48:08PM +0900, liu xiaolu wrote:
> Hi, everyone,
> I am planing to implement "AssetPortability" in OpenSim,
> The basic idea is to let RegionServer get assets from a
> dynamic(user specified) AssetServerURL.
> 
> Very thankful for someone added "asseturl" and "inventoryurl"
> to the userprofile structure and the "Users" table.
> (though I do not know exactly what it was he did)
> 
> Recently, I found there is a stub "GetUserAppearance" in "IUserService".
> This is a little different from what I am thinking, so here I would like to
> share my plan for the "appearance portability" and have a discussion
> with you.
> 
> # Preparation
> 1. User stores "wearables" in "inventoryserver"
> 2. User stores actual "assetdata" in "assetserver"
> 3. User tells its "asset/inventory url" to "userserver"
> (by user registration or someway like openid)
> 
> # Login
> At http://openugai.sourceforge.net/?page=openasset_proposal
> there are 2 possible patterns,
> "Implemetation 1" is following current opensim - "GetUserAppearance" in
> "UserServive".
> "Implemetation 2" is my proposal.
> 
> * Implemetation 1
> 1. "UserServer" acts as a agent, when "GetUserAppearance" called,
> 2. "UserServer" gets "wearables" from "inventoryserver"
> 3. "UserServer" gets "assetdata" foreach "wearables" UUID.
> 4. "UserServer" returns appearance to RegionServer(OGS1UserServices)

Actually, you have this flow wrong.

 1. Client -> Sim -> User Server (Get My Appearance)
 2. User Server -> Sim -> Client (Appearance Packet - lots of UUIDs)
 3. Client -> Sim -> Asset Server (foreach wearable get asset)
 4. Client -> Sim -> Inventory Server (foreach wearable get inventory)

If you look a little deeper on the GetUserAppearance data structures
you'll see that only UUIDs are flying around.  There will probably be a
caching of visual params as well, as it will make your ruth time when
you first log in smaller.

> * Implemetation 2
> "GetUserAppearance" is not in "UserServer", it should be a module or
> something
> independent. There is
> * "OGS1InventoryServices" incharge of communicating with "InventoryServer".
> * "AssetCache" gets "assetdata" from "AssetServer".
> I think we can use the 2 existing components to "GetUserAppearance".
> 
> Why I prefer "Implementation 2" ?
> 1. Just as UserServer does not provide "Inventory" information, UesrServer
> also should NOT
> provide appearance information.
> (UserServer should be concentrated on providing basic user information and
> the authentication.)
> 2. If UserServer have to fetch Complete "Appearance", UserServer must know
> about AssetServerUrl,
> and something like "AssetCache" must be implemented inside UserServer. This
> makes UserServer
> become less indenpendent.

That's actually not true.  With the user server storing asset and
inventory ids, the client is sent a wearables packet, which is just a
bunch of UUIDs.  The client then goes and fetches the assets from the
asset servers.

> 3. "Appearance" can be thought as "a special inventory folder called
> 'wearables' ".
> (InventoryServer is born to do such things)

I think that mapping "special cases" onto existing services is trouble
waiting to happen.

    -Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20080514/2e51c84f/attachment-0001.pgp>


More information about the Opensim-dev mailing list