[sldev] [source] Purpose of /newview and libraries split?

Strife Onizuka blindwanderer at gmail.com
Tue Jun 24 13:44:20 PDT 2008


Many years ago the client was named "newview" but it was not the first
iteration of the SL client, it was (atleast) the second; "new" is a
prefix to differentiate it from the client before it. Much later
during the push for the 2.0 renderer the source code layout got
reorganized into what you see today (and the exe was renamed to the
current naming semantic). The "newview" layout is lava flow.

Strife

On Tue, Jun 24, 2008 at 10:01 AM, Soft <soft at lindenlab.com> wrote:
> On Tue, Jun 24, 2008 at 7:48 AM, Dale Mahalko <dmahalko at gmail.com> wrote:
>> What is the reason for the dividing of some source files into the
>> /newview directory? I see lots of functional duplication across
>> /newview and the other directories, so it's highly unclear to me what
>> the code division is meant to accomplish. For example, there are some
>> sound-system files in /llaudio and some in /newview
>>
>> I realize that LL is also working on simulator and asset code we
>> cannot see, and it seems possible that the code not inside /newview
>> may be utilized by these other components. For example, I would assume
>> there's a similar usage of the LLLFS and the APR in the simulator
>> code, as there is in the client code. But there's no way for an
>> "outsider" to know if that is true or not.
>>
>> Are open-source programmers able to freely modify any component of the
>> libraries and /newview? Can modifying the source outside /newview
>> cause unseen problems with server/asset code that may reuse those
>> libraries?
>
> Short answer: Ideally, more things should be split out of newview/ and
> into their own libraries. This would speed builds and encourage more
> modularity. A lot of larger components are in newview/ merely because
> they started there when they were small, and componentizing them
> hasn't ever stood out as someone's biggest itch so far. I have a
> feeling this may change as we move to VS2005, as monolithic projects
> interfere with the way it parallellizes builds.
>
> You can certainly break server code by modifying some of the common
> libs, but generally not if you're only modifying the implementation,
> not the interface. If there's a specific change you're thinking of,
> the best thing you can do is ask. Even if it does necessitate a server
> change, if it's a good change for the viewer, odds are there will be a
> benefit for the servers as well.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>


More information about the SLDev mailing list