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

[Melinda Green]

Tigro Spottystripes wrote:
> Melinda Green escreveu:
>   
>> Tigro Spottystripes wrote:
>>     
>>>    
>>>
>>> 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
>>
>>     
>
> is it not possible to prioritize different activities, like always
> making sure the most important things involved in keeping the client
> connected always have enough system resources to perform regardless of
> how much work other things have in mind? 

Not really. I mean you might be able to prioritize the value of 
particular services, but there are so many interconnected dependencies 
that you'll often need to initialize what appears to be a low-priority 
service earlier than you'd think because it's depended upon by some 
higher priority service.

Regarding resources (CPU cycles in this case), even if you wait for a 
quiet moment to initialize low priority services, there's no guarantee 
that it will stay quiet. You can't predict when a bunch of people are 
going to TP into your region for example.

> I imagine people wouldn't care
> much about inventory being sorted fast if they get disconnected, 

No, but they'll complain about incorrectly sorted inventory when they 
don't.  ;-)

> things
> with less priority might run slower, and everything that would cause
> issues if done without other things having finished first should check
> if the requirements have been met, and if they haven't, check if they
> are in the process of getitng done, if not, ask them to start. Doing it
> like that, nothing should cause disconnections due to timeouts, and
> regardless of the current state, things would make the right state be
> achieved. So if the machine is powerful enough, everything gets done
> before the progress bar reaches the end, and if the machine isn't
> powerful enough, things will simply load up while they are used, in many
> cases people are used to things loading gradually, like objects loading
> from close to far, sculpty and textures progressively getting more
> details, avatars deruthing property by property (at least that used to
> be the case before Ruth got hidden away and replaced with the cloud or
> in some cases simply nothing), I believe people would handle it well if
> there was active indication of progress, no big stops in progress bars,
> and no repetitive animation that doesn't differentiate beginning from
> middle from end of operation, and things like indications of different
> steps , like text explaining what exactly is being done, or simply
> icons, colors or changes in the gui that are easily recognizable as
> individual stages etc are present;. Things shouldn't freeze other
> things,  gui should remain responsive,  connection essential operations
> should continue being triggered in time, things being done
> simultaneously shouldn't hog avaiable resources all to themselves, they
> should share  the resources, slowing down process depending on their
> priority, only things with very little priority should ever actually
> freeze to a halt for any noticeable amount of time, and there should
> never be doubt for the user about whether things are still working or
> have reached an irreversible unwelcome state (freeze, crash, or simply
> hav no idea what to do with the current condition/data and can't find
> it's way back to normal behavior etc). The user should always be given
> positive confirmation goals are being achieved, work is being done, that
> the client knows what it is doing and haven't forgot of the user. If
> some things already can be done while others are still being prepared,
> the user should be allowed to do them while not being left in the dark
> about the progress of what is not avaible yet.
>
>
> IMO, partial functionality, with information on what is missing and how
> long till is it avaiable is better than passively watching a progress
> bar, or having to wonder if the client will ever resume being
> responssive again.
>   

You just used the word "should" 11 times, and for the most part I agree 
that the code will ideally do all of those things, and in ways that 
don't confuse, irritate or overwhelm the user. There are ways of 
approaching all of the things you mention but none of them are easy.

-Melinda