[opensource-dev] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

On 2020-02-27 08:21 , Cinder Roxley wrote:
> On February 25, 2020 at 2:17:16 PM, Henri Beauchamp (sldev at hotmail.com 
> <mailto:sldev at hotmail.com>) wrote:
>> On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote:
>>
>> > Why are there changes?
>> >
>> > The viewer currently has some messages and costs hard coded
>>
>> They are _*NOT*_ hard-coded. The cost is modified after login on
>> receiving the EconomyData message (the process_economy_data() callback
>> is implemented in indra/newview/llviewermessage.cpp).
>> By the way, that's how OpenSIM grid can (and always could) deal with
>> different costs than in SL.
>
> Agreed on this point. When I implemented some of these same features 
> in an OpenSim grid, it was by extending the EconomyData message 
> combined with simulator cap.
>
The EconomyData message doesn't have all the dimensions that we needed 
to modify. In the new design, login supplies both the viewer and the 
simulators with the benefits data for each agent at login time (yes, 
this means that if you were to upgrade your account while you were 
logged in, the change would not take effect for any in-world purpose 
until your next login). This design allows us to have just one place 
where the benefits are established and everything gets the information 
from there either directly or indirectly.
>
> Won’t go into implementation issues with the way it was done because 
> it’s already been done, outside of mentioning the rampant 
> singletons-calling-singletons-calling-singletons pattern is 
> problematic. :)
>
I don't see how singleton usage is related to the benefits changes, and 
don't understand what problem you're describing, but I suggest that any 
followup for that be on a thread of its own.

>> Sadly, you used an LLSD sub-array into the LLSD map, and "old" viewers
>> (i.e. all viewers not based on LL's v3 viewer code for the XML RPC part)
>> do not know what to do with such an array (they can only deal with simple
>> key/value pairs, not with key/arrays); this was the case of my viewer
>> (but I thankfully and by pure "luck" noticed the issue a few weeks before
>> LL did stealthily modify the login server on the main grid, because the
>> beta grid already had the changes which caused me to fail to login in it
>> at that time, and I could diagnose and fix the issue).
>
> Lost a day out of my weekend diagnosing and resolving this in 
> LibreMetaverse/Radegast-ng. It really is a death blow to the 
> unmaintained OMV library. Heads up before this kind of deployment 
> would be very appreciated.
>
The definition of LLSD and our open source implementations of it have 
always included the possibility of arbitrary nesting in arrays and maps 
(and we use it extensively internally without problems). We're not able 
to constrain our designs to maintain compatibility with incomplete 
implementations we may not even know about, much less ones that are 
unmaintained.

> > Where are the changes?
>> >
>> > The changes are in the 'DRTVWR-481
>> > <https://bitbucket.org/lindenlab/viewer/branch/DRTVWR-481>' branch in
>> > the viewer git repository. A viewer built from that branch will be
>> > available as a Release Candidate soon.
>>
>> It would have been nice to give a sufficient forewarning to avoid 
>> breaking
>> the login process on the main grid for many viewers (or viewer versions):
>> Radegast, my viewer (all versions before v1.26.24.2 are unable to login
>> in SL any more), OMV, etc, etc, etc.
>
> Seconded. Always appreciated when API changes are documented on the 
> wiki as well.
>
I admit that I expected that an entry in a map that you didn't expect 
wouldn't be a problem; I assumed that it would be ignored (as it is in 
ours) and that it would be more useful to give you changes when there 
was something you could test against. I suggest that in the future your 
implementations be guided byPostel's Law. 
<https://en.wikipedia.org/wiki/Robustness_principle>

That having been said, we'll try to provide more advance warning for 
future changes when possible. Note that the further in advance the 
notice comes, the less specific and actionable it can be.

-- 
OZ LINDEN | VP Second Life Engineering
email: oz at lindenlab.com <mailto:oz at lindenlab.com> | Scott Lawrence 
<https://www.linkedin.com/in/scottdlawrence/>
LINDEN LAB | Create Virtual Experiences <https://www.lindenlab.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/3fa8b0d9/attachment-0001.htm