[sldev] Source reorganization needed

Dale Glass dale at daleglass.net
Tue Aug 28 03:04:12 PDT 2007


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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070828/1f978c96/attachment.pgp


More information about the SLDev mailing list