[sldev] s/Second Life/Snowglobe/g

[Tigro Spottystripes]

isn't there some spots where the grid or other LL services are referred
to as "Second Life"?

Dzonatas Sol escreveu:
> Since you have already started to tackle the name change, I ask for a 
> bit more thought on this path. SECOND_LIFE, and even the two letters LL, 
> has been known and used for all things related to the viewer (UI), 
> server, render engine, and network. That has worked in general so far. 
> With a variable name like VIEWERNAME, however, it is explicit to the 
> viewer and maybe with the render engine and network bundled together it 
> implies those also. What happens when one separates the viewer (UI) from 
> the render engine and network parts. What do we call the render engine 
> and network? Or perhaps the render engine and network is best known as 
> Snowglobe and viewer is a client of Snowglobe's render engine and 
> network? I hope you see this issue I bring up here.
>
> Maybe the best way to think of it is in Debian terms. What if (in Debian 
> world), the render engine and network code is distributed as 
> libsnowglobe.so and the viewer (UI) that loads libsnowglobe is 
> distributed as.... as what?  Snowglobe also? If this is fine with 
> everybody then ok!
>
> If you think it needs more thought than that, maybe there needs to be 
> [RENDERNAME], [NETWORKNAME], [SERVERNAME], or something else that is not 
> bundled into VIEWERNAME that would work when there is no UI code (i.e. 
> just the shared library for a render engine and network code).
>
> Cache will be cleared after you restart Rosebud
>
> Rob Lanphier wrote:
>   
>> ...
>> Here's my thinking on how to tackle this.  Let's do the least disruptive
>> thing for now, which is to replace the instances of [SECOND_LIFE] in the
>> "Viewer" category with [VIEWERNAME], and then make
>> [VIEWERNAME]="Snowglobe"  Since  we're not likely to change the "Second
>> Life" string for those in this release, we can leave the others
>> "SECOND_LIFE" for now.  There's a lot of bikeshed arguments about what
>> to name the other categories, but it'll be more obvious not only what to
>> name the new token but where it should be sourced from at the time that
>> we're ready to change those to other values.
>>
>> Sound reasonable?
>>
>> Rob
>>   
>>     
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>
>