[sldev] "Prim Journal" size

[Tigro Spottystripes]

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...)

ps:I do know there have been many right decisions as well, no need to
get all defensive, I do appreciate the huge accomplishments that have
been achieved by people working on Second Life and the underlying and
surrounding systems

Boroondas Gupte escreveu:
> Dale Mahalko schrieb:
>> Perhaps what is really needed is the capacity for a load-in of prims
>> to be backed-out via a form of disk-partition journaling /
>> transaction-tracking. If the parcel is found to be full when the
>> load-in is asynchronously completed by the asset system, it can be
>> safely backed out from the journal data.
>>   
> Sounds good. I think this should be the way to go if Tirgo's
> suggestion of counting the object's prims before the actual rezzing
> isn't possible (e.g., because that would require some recursive asset
> server queries with unknown reaction time).
>> But next you run into problems of deciding how big this journal should
>> be, since it adds more processing burden to the sim, to track the
>> rezzing of everything in the sim in order to permit rez back-out.
>>
>> If a sim allows 15,000 objects then the journal should probably be a
>> few multiples as large, since it is apparently theoretically possible
>> to attempt to rez a 15,000 prim coalesced object in an empty sim. If
>> two people try this at the same time the journal would need room to
>> buffer the insane amount of rez overflow, and not wreck the rest of
>> the existing sim.. so a 45,000 prim journal should be unreasonably
>> large enough. :-)
>>   
> Is this size really necessary? I'd assume a coalesced object is
> represented on the asset server as a list of references to the
> contained objects + their relative position/orientation. The inventory
> itself has a reference to that list. So, when a (no-copy) rez is
> requested,
>
>     * remove the reference to the list (i.e. the coalesced object)
>       from the inventory, but keep a copy of that reference in the journal
>           o also, don't delete the list from the asset server, yet
>     * try the actual rez
>     * if the rez fails (for whatever reason)
>           o roll back the emergence inworld of the already rezzed
>             parts, e.g. in the same way as that's already done today
>           o roll back the removal of the coalesced object from the
>             inventory by re-inserting the reference saved in the journal
>     * if the rez succeeds
>           o tell the asset server to abandon the coalesced object
>           o clean up the journal by removing the save reference
>
> So, if my assumptions are correct, the journal would only need to be
> able to hold as many references as there would be concurrent rez
> request being worked on. All the rest of the data would already be on
> the asset server and we would just have to keep it there for some
> short time longer.
>
> cheers
> Boroondas
> ------------------------------------------------------------------------
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges