Apparently, the extra entries are for more efficient upload. Unless a grid specifies the policy they want, open download and the inefficient upload mechanism will be in effect for it.
Melanie On 15/11/2012 11:32, InuYasha Meiji wrote: > Sorry, this is what I get for writing email at 5:31am. So you are > saying I would have to give you the gridinventory service link in order > to choose to suport this service. Ok then I guess I am goo dfor now, > just won't give that info out. Sorry I got confused. > > Inu. > > > On 11/15/2012 4:44 AM, Snowcrash Short wrote: >> Hi >> >> I've been working on a client side tool for decentralizing user >> inventories, which I will release as an open source tool in two weeks, >> some of the features may be relevant to grid operators. >> >> The basic premise of the tool is that the inventory and the backing >> assets of the inventory items really should be controlled by the user. >> The tool is born out of a frustration of having visited a number of >> grids. Each visit to a new grid presents me with an empty inventory, >> and I can then spend time searching for suitable item, clothing, >> attachments and other accessories. >> >> For this purpose I have created a tool which will allow me to backup >> my inventory to a local cache and then upload the contents to another >> grid. >> >> If my tool becomes popular, both the upload and download mechanisms >> may have some impact on the grid-operators, hence this email to serve >> as a notice. >> >> The basic architecture is pretty simple, consisting of a number of >> import agents, which can import the users inventory and backing assets >> to a local database, and a number of upload agents which can upload >> inventory content to a specific account. >> >> Backup/Import >> There are two import agents, one which will import .iar files and one >> which works very much like I believe "Stored Inventory" works, which >> can backup the inventory of an avatars inventory. Avatar backup/Import >> is governed by a policy. Currently there are two policies, >> one complying with a very restrictive interpretation of the Linden >> Labs policy on backups, and a completely unrestricted policy, where >> anything that can be downloaded will be downloaded. >> >> When a new account is registered in MyInventory it checks if the >> account is for a Linden Lab grid and limits the choices of policies to >> policies suitable for LL's TOS, I cannot and do not know if other >> grids have similar policies, I can well imagine that Avination has a >> similar restrictions, and would like similar logic implemented to >> restrict the download. Any grid operator which would like to have >> backup governed by a more restrictive policy are invited to notify me >> and I will attempt to implement the policy prior to the first release >> of the source code. or supply patches at a later time. >> >> Upload/Export >> MyInventory supports two mechanisms for uploading inventory >> content, traditional upload using UDP/CAPS and direct access to the >> inventory and asset web-services. >> Due to limitations in the UDP/CAPS protocol each upload will create >> new assets, and as of my latest read of the Open Simulator code the >> asset store does not support "single instance assets", i.e. it does >> not use a checksum to verify if the asset already exists, for this >> reason MyInventory prefers to upload using direct access to asset and >> inventory web-services. >> >> I would propose that the grids which chooses to support MyInventory >> augment their "GridInfoService" entries with the url's for the asset >> and inventory web-services, e.g. >> >> [GridInfoService] >> assets = http://assets.osgrid.org >> inventory = http://inventory.osgrid.org >> >> Best regards >> Snowcrash >> >> >> _______________________________________________ >> Opensim-users mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-users > > _______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
