[sldev] s/Second Life/Snowglobe/g
Dzonatas Sol
dzonatas at gmail.com
Wed May 20 18:41:25 PDT 2009
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
>
More information about the SLDev
mailing list