[sldev] Source reorganization needed

[Michael Miller]

Although I've only worked with the source a little bit, I'd have to
say that it's pretty bad. A few major quirks in the code:
1. It uses lots of global variables. This is great for hacking, but
downright horrible code technique.
2. It makes its own classes for things that already exist. For
example, why not use the Boost Threading library instead of LLThread
and LLMutex? Most people are probably more familiar with the Boost
library anyway. The code has near-no documentation, so it's best to
use well documented libraries instead of rewriting code with no
documentation.
3. A major lack of documentation. There's no document that explains
what each file does. This is unquestionably necessary for source code
of this size, so someone who is new to the code can get acquainted
easily.
4. The reliance on external libraries in separate downloads. The code
should be included in a single download. If this is not possible
because of copyright reasons(i.e. the library owners won't license
it), then there should be a shell script or batch file that downloads
them for you. It's a pain to get the source code, libraries, artwork,
fmod, quicktime, and more, just to get a basic source tree. Everything
needs to be included easily.
5. The major pains in getting compilers to work. For example, Lindens
still uses VS2003 to compile. Why is it a relative pain to get VS2005
working? Quite frankly, it's not bleeding edge, and it's what most
everyone developing c++ on win32 uses now, since they have a free
edition. All compilers that are latest-generation(that's not bleeding
edge) needs to be supported out of the box. As VS2008 rolls
around(with support for multiprocessor/multicore compiling),
supporting the latest compilers becomes very important.

Personally, I'd say either MAJOR code reorganization with massive
amounts of documentation(i.e. documentation for every function in
every file detailing arguments and returns) or entire rewrite of the
code from the ground up(probably too expensive to happen). To me,
Second Life looks like a hacked-together piece of software that won't
sustain itself in the long run. Something needs to be done about it.

-- Mike
On 8/28/07, Dale Glass <dale at daleglass.net> wrote:
> The more I try to add, the more I bump into the inadequacies of the
> viewer's architecture.
>
> Examples:
>
> One handler per message. Easy to solve. Will do work on allowing
> multiple ones soon.
>
> Bigger one: Assumption in the source that everything is done by only one
> part of the source code, and there aren't unrelated things that want to
> use the same message to communicate with the grid.
>
> For instance, I've got several projects in development:
>
> Event list: shows particle and sound sources, who owns them, etc.
>
> Chat log patch: Shows who is speaking, owner for objects who speak.
>
> These are already bumping into some troubles. For example both need to
> send the RequestObjectPropertiesFamily message to the grid.
> Additionally, the selection manager does that as well.
>
> Now, what do do about it?
>
> 1. As suggested by somebody else, trick the selection manager into
> requesting the data on the interesting object. I REALLY dislike this
> approach as it involves subverting something entirely unrelated for my
> purposes. Potential bizarre bugs due to putting the selection manager
> into an unexpected state.
>
> 2. Just copy/paste the message sending code everywhere it's needed. This
> approach seems to be used to some degree in the viewer, for example
> ChatFromViewer is used by both LLChatBar and LLViewerCircuit::sendReply.
> This seems to be the easiest option to take so far, but it's
> undesirable. There's code duplication (probably harmless though, as it's
> my understanding that message format isn't going to change), and
> opportunities for efficiency can be lost.  If there are 3 places that
> want something, and that something can be cached, it's inefficient to
> have them unaware of each other.
>
> It creates development problems too, as having multiple feature branches
> doing that means having to deal with conflicts in the common areas they
> touch.
>
> 3. Refactor the source in such a way that there's some object that takes
> care of it, and is used by the rest. This is easier said than done
> though, because this route seems to lead to rewriting the viewer in such
> a way that it's built on top something similar to libsecondlife. This
> would be a very nice thing, but it's a big project and not exactly the
> thing I have in mind when I decide to do some work on something that
> should be a small patch.
>
> I suppose a way of doing this would be to make a C++ libsecondlife-like
> library and making the viewer work on top of that. IMO this would make
> plugins much easier too.
>
> So, anybody thinks we should go with option 3 and move things around a
> bit? Anybody interested in working or already working on it?
>
>
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
>