[sldev] "Prim Journal" size

[Sean Linden]

On Thu, Jul 9, 2009 at 5:02 AM, Tigro Spottystripes <
tigrospottystripes at gmail.com> wrote:

> it's not possible to know how "big" an object is before rezzing it? That
> is kinda lame, it's like trying to copy a file from a disk to another,
> waiting several hours as the copy happens, and then eventually a dialog
> box pops up saying the system bit more than it can chew and the file
> doesn't fit whole in the new disk. Objects, coalesced or otherwise,
> should be stored with a header or some other associated fast to read
> piece of data that specifies how many prims it got, I'm kinda surprised
> they don't do it like this already (though considering all the decision
> errors that have been pilling up over time I probably shouldn't be
> surprised about things like this...)
>
>
There is already work under way to add the ability to have per-asset
metadata without having to put it in the inventory databases, though I don't
personally know how it's going to be implemented or if that decision has
even been made yet. If it's stored per asset on the asset servers, it
probably couldn't be displayed right in the inventory window because that's
a lot of extra fetches and loading inventory definitely doesn't need to be
any slower.

This could also potentially be displayed by doing a range GET to grab just
the header of the asset, again in a separate info window since that's a lot
of GETs. Though I'm not sure exactly what the format of a coalesced object's
asset is, so the data may not be at the beginning of the file.

I can't guarantee this will be implemented any time soon, but I'd suggest
opening a PJIRA with the request.

BTW, part of the reason we haven't added extra information like this all the
time in the past is that the inventory tables have around half a billion
rows each, so adding columns is fairly impractical. Once we have extensible
metadata storage it should be a lot easier to add stuff like this. Also,
there's that "don't make loading inventory slower" thing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090709/c5574801/attachment.htm