[sldev] s/Second Life/Snowglobe/g

[Dzonatas Sol]

I don't think there is confusion about that point. That path is obvious 
enough.

For those of us that need some way to refer to LL code in difference to 
their/our own code being bundled together, we also don't want to cause 
disruption where we now refer to Snowglobe (i.e. libsnowglobe.so) 
without the default viewer.

The cache is not part of the UI. You can't click on a cached asset. My 
Blizzard viewer may implement a LUA script, for example, that implements 
a click on its own UI. It has its own unique skin all written in LUA. 
However, it may have to handle a message like, "The new skin will appear 
after you restart [VIEWERNAME]." Ok, so I change [VIEWERNAME]="Blizzard" 
instead of Snowglobe. Now it has to handle the message, "A new version 
of [VIEWERNAME] is available." Now, that's not quite true since users of 
Blizzard won't need to download the full Snowglobe software, as they 
just need libsnowglobe.so. This is an example of where I ask for a bit 
more thought. Another example, "Cache will be cleared after you restart 
[VIEWERNAME]." If libsnowglobe.so exists then the Blizzard viewer can 
automate that step and unload and reload libsnowglobe.so. Of course one 
can hack all instances of [VIEWERNAME] to fit a new UI, but what if the 
message comes from the Second Life grid? How is the Blizzard viewer to 
know if [VIEWERNAME] should be replaced with Snowglobe or with Blizzard?

Just thinking outside of the official box.

Kent Quirk (Q Linden) wrote:
> Wow, speaking of ambiguity -- what I *meant* -- and where the 
> confusion may be coming from -- is that those messages that clearly 
> refer to the viewer should be fixed now, and the messages that refer 
> to other parts of the system should be debated and resolved later.
>
> On May 21, 2009, at 9:01 AM, Kent Quirk (Q Linden) wrote:
>
>> That's exactly the point of Rob's proposal. The viewer is unambiguous
>> and not particularly controversial.
>>
>> The rest of it is open to delightful amounts of bikeshedding. His
>> proposal is to fix the viewer only for this round, and have the rest
>> of the discussion later.
>>
>>     Q
>>
>> On May 20, 2009, at 9:41 PM, Dzonatas Sol wrote:
>>
>>> 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
>
>