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 > > _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
