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

[Tigro Spottystripes]

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.