[Opensim-dev] Rethinking inventory

[diva at metaverseink.com]

Thanks for your descriptions Melanie. I had hunch that fetching the 
entire inventory was wasteful and an unnecessary management overhead, 
independent on whether regions have access to it or not. Just wanted to 
make sure I wasn't missing something. I'm going to proceed with the 
exact same interface/service implementation that we currently have, but 
with the expectation that this will be improved soonish.

As already noticed, the service connectors will allow a wide variety of 
inventory behaviors. For core, we should settle on one or two that are 
reasonable, and that give enough information for how people can write 
their own. (I know jhurliman is eagerly waiting for me to finish this 
refactoring, he already has connectors for the CB2 service)

With appropriate changes to the client, it will be possible to support 
two kinds of inventory: (a) one that is the user's inventory, 
independent of any world, and that is accessed directly from the client; 
and (b) inventory that is user-world-specific. For now I'm going to 
focus on (b), since this is can be done on the server side. (a) is 
already prototyped in Grider, and it will have to wait until some of us 
start working on the client side.

So basically, I'm going to ignore the potential of 
WebFetchInventoryDescendents, because the way it is designed it either 
points to the regions or to the inventory server, in a mutually 
exclusive manner.

[point at which the participation of Linden Lab staff in the discussion 
would be very welcome]


Melanie wrote:
> A service could be written that does just that. But it should not be 
> the default.
> 
> Melanie
> 
> Frisby, Adam wrote:
>> Infact, GetAllInventory could be detrimental to the server on a large inventory.
>>
>> Personally, I would be in favour of some kind of 'automatic subdivision' of folders. Eg, when you take an object to inventory, it gets default saved into a folder for the week. (eg, 'Objects' -> 'From 2009/15' -> 'Object Name' [if the folder doesn't exist, create it.])
>>
>> This would reduce the size of the 'selects' and allow larger keys (which reduce overall lookup times -- albeit clientside search does diminish a lot of the gains here.)
>>
>> Adam
>>
>>> -----Original Message-----
>>> From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>>> bounces at lists.berlios.de] On Behalf Of Melanie
>>> Sent: Sunday, 7 June 2009 11:23 PM
>>> To: diva at metaverseink.com; opensim-dev at lists.berlios.de
>>> Subject: Re: [Opensim-dev] Rethinking inventory
>>>
>>> Hello Diva,
>>>
>>> to answer your questions:
>>>
>>> The inventory skeleton is fetched on login and sent to the client.
>>> It contains (or SHOULD contain) the actual folder serial numbers. I
>>> believe they may not currently be correct, though. The client
>>> decides, on opening a folder, which are out of date (by the serial
>>> number) and requests them.
>>>
>>> I implemented the serial number thing not too long ago, before then,
>>> inventory was always completely reloaded, the client cache was in
>>> fact defeated. In part, that is still so (see above).
>>>
>>> Inventory was implemented in a rather simplistic manner, sending the
>>> entire inventory in a single transaction from the inventory server
>>> to the client. This was never really necessary, and often not even
>>> useful, since all inventory transactions depend on the root folder,
>>> and it can't be loaded without loading all folders.
>>>
>>> A better inventory service would load inventory to regions only when
>>> it needs to be loaded, and the cases where that is necessary are
>>> surprisingly few, and most could get away with just the folder
>>> skeleton and individual items.
>>>
>>> I believe that I could get away with a function that will fetch only
>>> the user's root and system folders' UUIDs, since they are what is
>>> needed for inventory gives.
>>>
>>> For take and rez, the client already knows the folder IDs. So
>>> dropping inventory on a user and scripted gives are the two things a
>>> region does with client inventory.
>>>
>>> About letting the client talk to the inventory server: It needs to
>>> remain possible to do it through a region, as some grids are not
>>> willing to expose their inventory (asset, grid, etc) server ports to
>>> the internet. The region could, however, just verify the session and
>>> pass the request on.
>>>
>>> Session_lookup doesn't work. It was an attempt to secure the
>>> inventory server that failed because of session caches. If the
>>> inventory server needed to be restarted, it all currently logged in
>>> users would lose inventory access until relog. It was found
>>> architecturally flawed and not salvageable, so was turned off by
>>> default and recommended to be kept off. New implementations don't
>>> need to support the mechanism.
>>>
>>> So, a possible interface could be:
>>>
>>> class UserInventory
>>> {
>>> 	UUID RootFolder;
>>> 	Dictionary<int, IventoryFolderBase> SystemFolders; // System
>>> folders by content type
>>> 	List <InventoryItemBase> Items; // Cache for those items a region
>>> actually uses
>>> }
>>>
>>> interface IInventoryService
>>> {
>>> 	UserInventory GetInventoryBase();
>>> 	List<InventoryFolderBase> GetInventorySkel(); // Used by
>>> userserver
>>> for logins
>>> 	InventoryItemBase GetItem(UUID item);
>>> 	List<InventoryItemBase> GetFolderItems(UUID folderID);
>>> 	bool StoreItem(InventoryItemBase item); // Will overwrite by UUID
>>> }
>>>
>>> GetItem() is needed to push newly acquired items to the client as
>>> well as to verify that asset IDs given by the client on rez are
>>> correct. We currently don't trust the IDs the client produces, and
>>> we shouldn't.
>>>
>>> GetInventoryBase is what the "give" class of functions would call on
>>> users who are not logged into a region. We may want to call that
>>> when a user enters the region, but possibly we can actually get away
>>> with not obtaining any inventory information at all unless an object
>>> gives something to the user, or another user does.
>>>
>>> Note the distinct lack of a "GetAllIventory" type method... it's not
>>> needed.
>>>
>>> It may need a few more specialized methods, but this should be about
>>> the size of it.
>>>
>>> Melanie
>>>
>>>
>>>
>>> diva at metaverseink.com wrote:
>>>> Also, are there any grid operators out there who run their inventory
>>>> servers with the configuration session_lookup = true ? (this is a
>>> flag
>>>> in InventoryServer_Config.xml)
>>>> Just curious to know if this is being used.
>>>> _______________________________________________
>>>> Opensim-dev mailing list
>>>> Opensim-dev at lists.berlios.de
>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>>
>>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>