[sldev] [VIEWER] Dead code removal

[Kelly Linden]

Lawson English wrote:
> Kelly Linden wrote:
>> Lawson English wrote:
>>  
>>> Bryan O'Sullivan wrote:
>>>    
>>>> Dirk Moerenhout wrote:
>>>>      
>>>>> True but I'm mostly referring to parts of newview and I hope it is at
>>>>> least so that this is never used by the server code.
>>>>>         
>>>> It's best to keep the dead code removal in a patch of its own.  That
>>>> makes it easier for us to review patches.
>>>>
>>>>      
>>>>> It might even be
>>>>> a good question: What do we really share with the server code? I
>>>>> guess
>>>>> we probably share llcommon but what other parts are dangerous too?
>>>>>         
>>>> You can see the exact lists of libraries that the viewer and server
>>>> depend on in the SConstruct file that ships with the source.
>>>>
>>>> A lot of the libraries are shared.  The easiest rule of thumb is to
>>>> assume that any ll* directory that isn't related to drawing windows
>>>> or other bits of UI is likely to be shared with the server code.
>>>>       
>>> I'm confused... The client build ships with server-only  libraries
>>> included?
>>>
>>>
>>>     
>> No, but some of the libraries used by the client are also used by the
>> servers.  This means that some code in the libraries that appears to be
>> 'dead' from the viewer perspective may not be, if any of the server code
>> relies on it.
>>
>>  - Kelly
>>
>>   
> Pardon me if this sounds like a bad library design to me, unless that
> code is definitely designeed to be "dual use" between client and
> server like common definitions and communications modules, and in that
> case, it should be factored into its own files and placed in the
> "common" if I understand what that is for.
>
> (I'm on a refactoring warpath with the GUI, sorry if I sound a bit
> extreme today).
>
The cases where this happens the code is indeed definitely designed to
be "dual use" and are generally common definitions - although not always
of communications modules.  The server and client often need to share a
lot of data - to have a common representation of what an inventory item
is or a parcel is for example.  That isn't to say it couldn't be better
designed, there are LOTS of places where the code could be better
designed, as I'm sure you are aware if you are on a refactoring
warpath.  Most of the cases of shared code though aren't that bad, and
the alternatives could be worse.  Could you imagine the pain of a
permissions system implemented separately in the viewer and the server? 
It is bad enough as it is.  :)

For the over all project layout, it should probably be clearer where
this happens.  Perhaps llcommon should really be a directory with many
projects in it, rather than the single project is it now, although I
think there may be reasons we have preferred a flatter hierarchy.

 - Kelly