[sldev] Why hasn't Linden Lab implemented WRITING to NOTECARD?

[Melinda Green]

Tigro Spottystripes wrote:
>  I believe I understood most of what you said. The client does many
> analysis on the contents of the inventory each time any new info about
> it comes, so with a big inventory there is lots to do each time, and
> lots of times. But your explanation raised two questions IMO,why the
> client can't walk and chew bubble gum at the same time, 

That question makes no sense. Obviously the client does lots of things 
at once and that complexity contributes a lot to these problems.

> and why it was
> allowed to think it got the whole inventory when it doesn't. 

Uh, maybe because there's a bug in there somewhere that hasn't been 
squished yet?

> Actually, 3
> questions, the rhird is why the client was allowed to have the login
> process be so fragile while at the same time throwing heavy things into
> the login process.
>   

Because it grew organically, one feature at a time the way living 
software does. Of course feature addition needs to be balanced with 
refactoring activities to keep things manageable, but those activities 
do happen to, maybe just not at the level that they should. In short, 
creating a vibrant, self-sustaining world is hard. At least your 
questions are easy!  :-)

-Melinda

> Dzonatas Sol escreveu:
>   
>> If you look at LLGestureManager, you'll notice that it has "listeners"
>> that watch changes to the active list of inventory items (for gesture
>> in the case of LLGestureManager). When a change happens, then a
>> routine is called that reads the active list, sorts the items, and
>> builds arrays of data for later processes like combo boxes, or search
>> keys, and more. The problem is that it does a fresh sort every time
>> the list is touched. That means as the login process happens, about
>> the point where the progress meter reaches just beyond half way, it'll
>> send and receive inventory requests and sort all that data over and
>> over again for each special list for each item received. If you've
>> messed with the login process at all, you'll find that it is really
>> easy to timeout the login process. Most likely, if you have 30K
>> objects, you are well beyond the possibility of sorting those lists a
>> couple ten thousand times before you appear in world. This further
>> means that any time spent too long to sort those lists could lead to
>> packets being dropped. If I haven't confused you yet, then you would
>> realize that after you login, it could be very easy for you entire
>> inventory not to appear, and you'll have to refresh it (manually)
>> where you'll have more luck to complete the inventory download since
>> the local cache has already has stored many of the recently requested
>> assets, which means it doesn't have to request all the inventory from
>> the server the next time around.
>>
>> Anybody, feel free to explain that easier, go ahead! =)
>>
>> Tigro Spottystripes wrote:
>>     
>>> Interesting, much more comprehensive than I expected, but can you
>>> explain me why the client doesn't got such a thorough capability of
>>> reading the inventory? (the total item count for my inv varies from
>>> about 9k to 30k+ depending on my luck, regardless of how many items I
>>> add or delete) Or does the check randomly misses things in the inventory
>>> like the client do?
>>> _______________________________________________
>>> Policies and (un)subscribe information available here:
>>> http://wiki.secondlife.com/wiki/SLDev
>>> Please read the policies before posting to keep unmoderated posting privileges
>>>
>>>   
>>>       
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>