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

Tigro Spottystripes tigrospottystripes at gmail.com
Thu Jun 11 04:58:47 PDT 2009


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? I imagine people wouldn't care
much about inventory being sorted fast if they get disconnected, 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.


More information about the SLDev mailing list