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

[Melinda Green]

Tigro Spottystripes wrote:
> Melinda Green escreveu:
>   
>> Tigro Spottystripes wrote:
>>     
>>> Melinda Green escreveu:
>>>  
>>>       
>>>> 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.
>>>>     
>>>>         
>>> >From what Dzonatas said, I understood that the client somtimes might
>>> bite more than it can chew and allows for things to time out during
>>> login instead of doing things in the background at the same time it
>>> makes sure the server doesn't think the client is gone.
>>>   
>>>       
>> Well, you can't have walking and chewing without some biting I guess. 
>> :-)
>>
>> I like Dzonatas' solution to defer sorting until actually needed for
>> display, if ever. If you like it too, then please notice that his
>> solution adds more complexity in the form of the dirty flag. If that
>> flag ever gets out of sync, then the list won't appear sorted.
>> Although there was previously a performance issue, that type of
>> synchronization bug was at least not possible. Was the performance
>> savings worth the complexity? Maybe so but I'd really rather find a
>> solution with less risk. Like perhaps only sorting when the drop-down
>> is opened. My point is not on what is the best solution to this
>> problem but simply that sometimes it's worth suffering some extra code
>> complexity and the inevitable future bugs that complexity always
>> brings. Bugs such as this one that seems to make you so upset. What I
>> don't understand is what your point is in insulting the code. Lots of
>> the viewer code is beautiful and lots of it is messy and fragile, but
>> calling it all stupid is almost the same as calling the developers
>> dumb which is not what we need.
>>
>> -Melinda
>>
>>     
>
> The way I would do it would be to make sure the client is completly
> logged in, before trying to make any less important tasks, IMO there
> seems to be too many things being done during login that could just as
> well be done before and/or after login has been stabilished, and have
> the client always prioritize staying connected over other things, never
> the other way around, there is no point in doing anything else if you
> endup disconnected (unless of course if it is after the user has
> requested to be disconnected)
>
> Any insults to the code, if present at all, were only meant to emphasize
> my surprise/disappointment with the existence of apparent flaws and in
> some cases add a bit of comical relief, I never meant to offend anyone.
> I understand that organicly grown software systems tend to get somewhat
> messy, that is often an inherent feature of orgagnicly developed
> anything, take a look a the human body :P
>
> There are great things and ingenious hacks around non-great things, but
> there are a great number of people who would have major changes done
> from scratch instead of built over existing mistakes done, I'm talking
> about the human body, but it also applies to the SL client.
>
> But I am aware that with complex systems, specially organicly developed
> ones, minor changes often produce unexpected results in things that were
> expected to be independent, I do appreciate the work done with SL, it's
> the type of thing that would be expected to not work and yet it does (to
> some extent depending on who you ask), t is amazingly fragile and yet
> unexpectedly robust, in many aspects it's kinda like the Antonov 225,
> too big to fly, reconditioned old tech, and yet it achieves greatly.
>   

Well, now that's the sort of analysis, suggestion, and tone that I think 
*is* helpful, thanks!

Regarding work done on log-in, if we defer doing all those things that 
you call  less important (to you, that is), then when the time comes to 
do all that work, if they happen all at once, then we're just going to 
delay the time before we suddenly grind down and get disconnected. 
That's assuming that all those things are atomic and independent, which 
they're not. Having spent a fair amount of time in that start-up code, I 
know too well what a delicate choreography it requires to make sure that 
each service is initialized before it's needed to initialize some other 
service. I spent the better part of a month simply turning about 50 
global pointers into proper singletons for exactly that reason. The 
reason it took that long was because of circular interdependencies that 
needed to be untangled, and this was only one small part of the start-up 
process. So I agree that it's almost a miracle that it works at all.

Taking your suggestion to it's logical extreme we would end up after 
enormous effort with services broken into clean modules that are 
packaged as shared libraries that get loaded the first moment they're 
accessed, if ever. I like that idea a lot but have to point out that 
it's not all upside. Aside from crashes that will happen when an attempt 
is made to load a module that didn't get packaged, or when the wrong 
version is loaded, users will then experience noticeable pauses the 
first time they access major components. Sure, log-in will be quick, but 
there will be a new kind of annoyance that happens when you go to do 
anything new. So there's value in initializing everything right up front 
and in a well-defined order, and there's value in initializing modules 
on demand, and none of the choices seem easy or obvious to me.

-Melinda