[sldev] "Unreferenced" assets

[Sean Lynch]

GC is the only way assets will get deleted (other than single reference
assets like scripted attachments, but that code is not in production yet),
so yes in any case that llGiveInventory needs to make a new asset, but I
believe that unless you're giving a no-copy object, a new asset isn't
created by llGiveInventory, just a new reference to the existing asset.

Am I missing something about the question? Leaked assets like this shouldn't
harm the giver in any way. They just take up space on the asset servers
until we get around to cleaning them up. This is way simpler and less error
prone than trying to detect the leakage in real time and clean stuff up
right away: storage is cheap. Complexity in code is not.

On Mon, May 19, 2008 at 12:35 PM, Vex Streeter <vexstreeter at gmail.com>
wrote:

> Is this GC process the (only) way that objects given by llGiveInventory()
> but refused/ignored/lost-on-viewer-crash get collected?
>
> Kelly Linden wrote:
>
>> Example:
>> * I upload a texture, or lets say 30 textures, one for each english
>> alphabet character and some punctuation.
>> * I use a script to get the asset IDs of each
>> * I put those asset IDs in an external application
>> * Each piece of my whiteboard polls my external service (via
>> llHTTPRequest) once per second to get the asset ID to show
>> * I know all the IDs, the scripts don't need to have them in inventory and
>> I don't need them clogging my inventory so I delete them all and empty my
>> trash
>> * My system now works with really simple lsl scripts .... until GC decides
>> that nothing is referencing the textures
>>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080519/b5516757/attachment-0001.htm