Jump to content

Suggestion: Incremental inventory design for Aditi grid.


Jenna Felton
 Share

You are about to reply to a thread that has been inactive for 3238 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

The Problem

Some residents do experience inventory problems last times when the inventory in Aditi, especially after password change (made to update the Aditi inventory) breaks. And I also read from indirect sources that the inventory on Aditi is on smaller hardware so there are needs to cull out data that are not used.

As I understood the asset index for Agni and Aditi are in separate databases while asset server has the files on disc (notecards, LMs textures, objects and so on) and every asset index just links the files for avatar and object inventories. This makes it easy to look up the inventory: Loading index is faster than the files.

But you have than to maintain both asset indexes for Agni and Aditi. You must keep them in sync, for example by copying the Agni inventory (the asset indexes) into Aditi inventory so you have an updated inventory there. This also wastes resources because you have to maintain two index databases with almost equal data, the one for Agni and one for Aditi, while for many residents that data are even not used (the residents not went to beta grid yet or went and left for good.)

And the question is now how to cull out the unused database indexes. I have a suggestion to solve that problem which bases on two principles:

 

  1. Don’t use redundant indexes
  2. Handle the beta inventory as joint of the inventory in Agni and items added in beta grid.

 

How to do that:

In the first step flush out the avatars inventory in beta grid except for items created or acquired in beta grid.

When the viewer in Aditi requests inventory from the server, the server passes the request over to the Agni inventory server. The result is then extended by items and folders the user added in Agni by creating the folders, notecards, objects picked fromworld etc.

So you always see the full inventory and everything you own in Aditi or agni. You see them here automatically, without needs to copy everything from Agni to Aditi first.

Now, if the user tries to perform an operation on inventory that affects the Agni inventory, and the operation would remove or alter the items (can you alter an item without making a copy?) than the operation is rejected with an error message. For example

 

  1. You are in Aditi and want to give out an item that is in your Agni inventory and is no copy. This would remove the item from Agni inventory – fail.
  2. You have selected an item in inventory and hit delete button, but you are in Aditi and the item is in Agni – fail.
  3. You open a notecard that is in your Agni inventory, edit and save it – accept. The new copy of the edited notecard is now in your Aditi inventory. If you go to Agni, and open this notecard, you still see the old text.
  4. You are in Aditi and rezz an object from inventory, or put this object into another object rezzed inworld. The object is in your Agni inventory and is copy. Ok, the new copy of this object is created and is in your Aditi inventory if you pick up the object fromworld.
  5. You are in Aditi and upload a mesh or image or sound etc. That all lands in your Aditi inventory which is in fact an extension of the Aditi inventory. You are free to rezz the mesh or use the notecard etc. If you go to Agni, you will not find the item in the place it is in Aditi.
  6. You are wearing a clothing layer or attachment, and this is in your Agni inventory and no copy. Because you have read access, the viewer can wear or attach it with no problems.
  7. You can also modify the item, the changes are saved in your instance of the item in Aditi, the changes are not passed over to Agni.

This way you have always a read-only access to your current Agni inventory from Aditi and must not change password in order your inventory updates. And the server load of the Aditi inventory is minimal, so you not need to cull out anything.

Actually you need only to change the servers (I hope) and add a new error message, or even extend existing error notification by new text, i.e. I hope by now this suggestion doesn’t affect the viewers at all.

But i would to go farther and extend also the viewer. I’d like to see the properties of inventory items extended by a new grid field telling if this is an item in Aditi or Agni inventory, so you can see if you have full access to the item or the read-only and you must not await the error message if you was wrong. This field the viewer has to display than at some way.

Possibly even more: “this item is in Agni inventory”, “this item is a modified copy of an item in Agni inventory” and “this item was acquired in Aditi”. If you go to Agni, the viewer displays only the first possibility.

Limits

This design doesn’t support deleting Agni inventory from Aditi login. Sometimes it is necessary. For example most Agni landmarks don’t work in Aditi and your favorites list is full in Agni, and you want it to list way other landmarks in Aditi. Although you can put some favorite landmarks in the favorites list also in Aditi, but have than troubles to find them under the amount of not working landmarks.

The solutions of that are filtering and hiding, which needs more altering of the viewer.

Filtering means you can set the viewer to filter folders and types of inventory items that are only in Agni inventory, so you don’t see them in Aditi. The filtering should be a separate setting for each folder and inventory type, so you can filter out all Agni landmarks or those in favorites list but nothing else.

Hiding means you explicitly hide an item or a folder from being shown in Aditi. This way you can refine the hiding criteria.

The disadvantage of that design is further, that by hiding or filtering inventory parts you create data for inventory index and can potentially make relatively much of them so the benefit of incremental inventory design looses.

For this reason I’d suggest to support filtering by grid property for every inventory item (this setting doesn’t increases with inventory), but restrict individual filtering and hiding only to the top-level folders and system folders (that are top-level actually) and their direct content. The subfolders and their content should be no more individual filter- and hide able.

That's all. Hope it willl give some constructire ideas, or start a usefull discussion.

 

Greetings
Jenna

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3238 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...