[sldev] Source reorganization needed

[Kelly Linden]

Dale Glass 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?
>
>
>   
In the past for cases similar to your "bigger" case, we have gone with 2
or "3 lite".  By "3 lite" I mean adding a "manager" for a specific set
of data that needs to be cached or shared by multiple pieces; LLGroupMgr
is an example of this.  In other words, rather than refactoring the
entire code base you could just refactor the piece(s) that you need.

 - Kelly