Jump to content

Inventory Archive Feature Request


Summer Seale
 Share

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

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

Recommended Posts

Hi there,

 

I'm not certain if this is the forum I should post in, or the server forum, but I figured I'd throw out this idea I had for a while.

 

Problem: Archiving stuff in SL is a pain in the butt. We all know it (unless I'm missing something). It just really is. Inventories tend to be absolutely huge and it's probably something which is costing LL a packet in terms of bandwidth as well.

 

Solution: Why reinvent the wheel? TAR has been here for decades. So has ZIP. Inventories are stored on servers, and servers can TAR and ZIP since the dark ages of computing. Why not make a right-click option to click on a folder in your inventory and select "Archive..." which will effectively tar everyrything in that folder and subfolders? No more rezzing boxes and having problems putting in a set amount of stuff, worrying about no copy/copy stuff to track, etc...just use what computers have had for gobs of years. Right-click, Archive, you're done. Delete the original folder if you want and your backup is tarred up as one single TAR or ZIP file.

 

Cleaner inventories, less bandwidth consumption, less clutter and way less of a hassle. Hours of sorting through stuff and putting them in plywood cubes are now gone.

 

Thoughts? Did I miss a better solution we already have? Please let me know. Also, if people like it and want me to make a JIRA or whatever, please let me know and direct me to the appropriate place.

 

I'd really love an inventory solution like this ASAP, and I think pretty much everyone else who has been in SL for more than 10 days would probably agree.

 

Thanks for any input. I do appreciate it.

 

Link to comment
Share on other sites

P.S. I realize that objects are not actually files on the server in the traditional sense, and are in a database. That's fine. But I'm pretty certain that a TAR or ZIP solution could be implemented with that in mind at any rate. Databases, or parts of them, can be compressed. There must be a fairly simple solution out there for it.

 

Link to comment
Share on other sites

a comprehensive backup ability is very very much needed.  I just lost over 10k of items, and LL tells me they are not recoverable or restorable.  Some of that was over 5 years of sculpting work, products, maps and textures.

Count me in.

 

Link to comment
Share on other sites

Yup that's what TAR and ZIP do They preserve perms on files on servers. Again: I know that objects aren't files on a server in a traditional sense, but the technology exists since decades to do this, even with databases. There must be a solution they can use that is almost out of the box. I'm not a coder, but I do know some basic things at least.

 

 

Link to comment
Share on other sites

I haven't understood Dres' referenced solution, I'll give it a second read later. Meanwhile, your proposal might be interesting as long as the resident understands that archived items will take significantly longer to retrieve, therefore giving the servers ample time to do the compression tasks thoroughly and thus achieve better compression... wouldn't do if such feature offered nearly instant retrieval at the expense of 1% or less compression plus additional complexity to the SL protocols.

Another thing is... would assets compress that much? I'm hardly a compression expert, I only know that for some contents, conventional compression schemes achieve space gains hardly worth the trouble, and only memory/time-expensive specialized algorithms such as RK and even more obscure ones, claim significant enough compression for these.

Link to comment
Share on other sites

Good points!

 

1) As for time: Right now, it takes gobs of time to archive things into little cubes you rez on the ground. You're limited by number, and it's a mess organizing it all. It also takes time to rez, and time to open and load. I believe that my solution would be at the very least slightly faster, and much easier to organize. I could dump all my old stuff in a folder, for instance, right-click and select "Archive" and it's done after compression. I then delete the folder and save a ton of item clutter in my inventory.

 

2)  Compression: I know that some things don't compress that much, but other things do. Pictures/text, text, and other things. The main point is to:

 

a) make a usable archive system - at the current time, I consider there to be absolutely no archive system whatsoever in SL.

 

b) have some compression advantages, but this isn't the main point for the users. However, any gain in compression would be an advantage to LL's bandwidth costs. If people were able to save even just 5% total on their inventories, or 10% (and I'm being exceedingly conservative here in some cases I think...) that would represent a gobload of money every month in savings for LL. So compression isn't much my concern as it is theirs.

What I want, and what every user wants (I believe), is a usable archive system. Anything else would be a boon to LL. But it's up to them to figure that out.

 

Link to comment
Share on other sites

Anyone who has been devoted to Secondlife for a long time would know the value of having such a system and what they've invested for themselves while in Secondlife do have a play in this kind of interest where their data would be forever archived rather than in prim boxes where even those sometimes disappear from their inventory.

I personally can't imagine how many megabytes, gigabytes or terrabytes are involved with each of our profiles and would think that after a decade (yes, i'm that old of an account) that everythign would add up to a lot of storage space and what would be needed to preserve that information; whic h i think would be very costly overall to both accoutn holders and to Linden Lab itself.

 

Anyways, i saw this request and think it'sa fantastic idea that should be endorsed!

Link to comment
Share on other sites

I agree completely. There has got to be a better long term storage system that is more secure than the current situation. With more and more content being non-transferable,  you can no longer even have an avatar just for storage. I've tried so many dffierent things and i know that i've lots many hundereds of dollars of invenotry on things that Can Not be repurchased because the creators are not longer in world.

 

A better solution has to be found tof benefit Both sides of the coin. Especially if you want more content creators, more artists, more machima, more stuff that the real world will take seriously. What do we say at a first showing "oops, it just dissappeared?" Come on, let's get a little professional here.

 

Link to comment
Share on other sites

I'm just wondering how I can get LL to respond to this idea. I think it's pretty vital for most residents to have this. It's a basic function of any computer and server. Even blogging sites have archive capabilities, not to mention CMS systems.

 

It's something so basic and it is completely lacking since SL's inception. Is there anybody who knows of a way to get LL to respond to this? And keep in mind: I'm not just asking for something for residents, but proposing something which might even save LL some money. Hopefully, that would be enough to get some sort of response.

 

BTW, for the record: I'm not talking about a backup/download system here. I'm talking about an archive system. It could very well evolve and act as some sort of backup/download system in the future if LL wishes it and others push for it, but my goal is just the simplest archive system I can imagine; the one which I envision being the easiest for them to install and implement. That's all. I want to leave the deliberations and debates about perms and downloading to another initiative, if anyone else wants to pick that up later on. All I'm asking for is the basic start of an archive system which would benefit all concerned. Something which I hope everyone could get on board with.

 

Link to comment
Share on other sites

I have been mystified by LL's failure to address this for the full 7 years I have been on SL. Yes, TAR/ZIP and Archive by all means, any means, if it will finally mean an avatar can move from one region to another without dragging the full load of a 20 to50K item inventory hit to the servers at once. Protected archives, even if it requires a small fee, would make SL more responsive, and emmersive. I fully support your efforts. The ball is squarely on LL's court to tell us if/why it can or cannot be done or help.

Link to comment
Share on other sites

Summer,

Unless I misunderstand how inventory works, your suggestion doesn't make sense to me. Although my inventory hovers around 10K items, the local inventory files on my Mac are relatively small. The largest is about half a megabyte. And I believe they are aleady compressed, as my inventory cache file names are of the form xxxx.inv.gz., where .gz is recognized by my Mac as a G-Zip file. So, my largest inventory cache file is about the size of one large texture.

The bulk of the storage space in a typical inventory is the text used to describe each item. The items themselves are referred to by UUID at eight bytes each. When you purchase a dress, you don't get a copy of the assets, you get the UUIDs of the dress' assets (textures, shapes, etc). The original assets stay wherever they were in the asset servers, unless needed for rez. And those assets are already compressed. Textures are stored as JPEG2000. Compressing them again via Zip or TAR would likely increase their size. (Zip a JPEG file and see what happens.)

If you wanted LL to archive your inventory, what would they compress, the text description/UUID list or copies of the actual assets? If a million residents have a copy of a 1MByte texture I created, it currently takes only 1MByte of storage space for the texture (ignoring whatever replication may go on in the server farm to speed delivery), plus a handful of bytes per resident to store the text description/UUID entry in each of their inventory files. If you wished to allow all those residents to make TAR archives including the actual texture, the additional required storage space would capsize SL.

This is analogous to the iTunes record library and their iTunes Match service. A substantial portion of my old record library has been recognized and matched by iTunes. It appears that I have 25GB of songs uploaded, but in actuality 20 of those 25GB are nothing more than references to tunes in their master library. They need only one copy of Fat's Waller's "Ain't Misbehavin" to satisfy more than 800 million subscribers.

I certainly would like to see better inventory management tools, and I think that's really what you're asking for.

Link to comment
Share on other sites

This is a fantastic idea and has to just be common sense. Sounds like a win/win and it would not surprise me if there are cheaper storage solutions for content that has a lower time-to- retrieval requirement. There are several ways of addressing this issue, it would be great if LL could look at some options.

Link to comment
Share on other sites


Madelaine McMasters wrote:

Summer,

Unless I misunderstand how inventory works, your suggestion doesn't make sense to me. Although my inventory hovers around 10K items, the local inventory files on my Mac are relatively small. The largest is about half a megabyte. And I believe they are aleady compressed, as my inventory cache file names are of the form xxxx.inv.gz., where .gz is recognized by my Mac as a G-Zip file. So, my largest inventory cache file is about the size of one large texture.

The bulk of the storage space in a typical inventory is the text used to describe each item. The items themselves are referred to by UUID at eight bytes each. When you purchase a dress, you don't get a copy of the assets, you get the UUIDs of the dress' assets (textures, shapes, etc). The original assets stay wherever they were in the asset servers, unless needed for rez. And those assets are already compressed. Textures are stored as JPEG2000. Compressing them again via Zip or TAR would likely increase their size. (Zip a JPEG file and see what happens.)

If you wanted LL to archive your inventory, what would they compress, the text description/UUID list or copies of the actual assets? If a million residents have a copy of a 1MByte texture I created, it currently takes only 1MByte of storage space for the texture (ignoring whatever replication may go on in the server farm to speed delivery), plus a handful of bytes per resident to store the text description/UUID entry in each of their inventory files. If you wished to allow all those residents to make TAR archives including the actual texture, the additional required storage space would capsize SL.

This is analogous to the iTunes record library and their iTunes Match service. A substantial portion of my old record library has been recognized and matched by iTunes. It appears that I have 25GB of songs uploaded, but in actuality 20 of those 25GB are nothing more than references to tunes in their master library. They need only one copy of Fat's Waller's "Ain't Misbehavin" to satisfy more than 800 million subscribers.

I certainly would like to see better inventory management tools, and I think that's really what you're asking for.

Inventory management is perhaps one of the most time consuming things we all deal with in life.

And it's only ever going to be as good as the "filing systems" we have.

Right click / send to........................

LL gives us a basic folder structure and also allows us to add to it.

They also give us ways to delimit our search when we need to find something in those folders.

So the only thing I can see that can be added is to give us an east way to 'hide things from ourselves' so our inventories don't look as full, which is what we do when we pack away things into boxes.

Which reminds me, I need to fold my laundry and hang up my shirts before they get all wrinkled.  :)

 

Link to comment
Share on other sites

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

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

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...