[sldev] "Prim Journal" size

[Sean Linden]

Sorry, I should have read the entire contents of the email before replying.
I can't think of any reason the limits couldn't be checked before rezzing a
coalesced object; even fetching every object and then fetching it again
would be fast because assets are cached by the local Squid cache. However,
this would still be no guarantee that the limit wouldn't be hit anyway,
because rezzing a coalesced object is not atomic. A way to temporarily and
atomically reduce the limit until the rez completes, like a temporary
authorization on a credit card, would probably be the best solution along
with counting prims in advance.

Disclaimer: I have looked at very little of the simulator code, so I have no
idea how practical it is to implement; I'm just making an educated guess.

On Thu, Jul 9, 2009 at 11:18 AM, Sean Linden <sean at lindenlab.com> wrote:

> 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/32bbe167/attachment-0001.htm