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. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
