[opensource-dev] Viewer changes for Premium changes

Cinder Roxley cinder at alchemyviewer.org
Thu Feb 27 05:21:00 PST 2020


On February 25, 2020 at 2:17:16 PM, Henri Beauchamp (sldev at hotmail.com)
wrote:

On Tue, 25 Feb 2020 10:48:03 -0500, Oz Linden (Scott Lawrence) wrote:

> *As we mentioned at the last Third Party Viewer meeting,

Oh yes, those meetings a non-English speaking developer cannot follow
because they are held in voice chat... How nice and practical a way
of communication !


Agreed. Even as a native English speaker, the meetings are not accessible
to those without access to voice. Summaries of the meetings on third party
blogs don’t really suffice for api breaking updates.

> 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.

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. :)

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.

> For example, one of the benefit tags is "texture_upload_cost"; its value
> is the number of L$ required for this user to upload a texture. The
> viewer displays that cost in the upload dialog so that dialog must be
> modified to use the value returned in the tag rather than the L$10 that
> is currently hard coded.

This particular usage is useless and redundant, since EconomyData/
process_economy_data() already can change that value in real time (and
in fact, it could even occur on a per-sim basis if needed, and not just
at login !).

Very true. It also handles the case where a customer changes premium levels
while logged in. They would only need a balance refresh not completely
exiting the viewer and logging back in (including an out of sync state
where an account is downgraded while the agent remains online.)

> 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 am (yet again) extremely disappointed with LL:
- No communication (a message in this list should have been posted even
before the change would have gone live on Aditi !),
- No forewarning (it's already too late for Agni as well !),
- No anticipation of the problems induced by the planed change,
- Not even a sane, simple, trivial precaution, such as respecting LL's
own viewer protocols design (here via the requested_options mechanism)
for something as essential as the login process !

Agreeing with this. There’s a wealth of knowledge that can be tapped into
via this mailing list that could have prevented some of these compatibility
issues. Remember that many of us have been blackboxing the API and
extending features without any access to the server side code for over a
decade now. Those of us with that breadth of experience rarely attend the
inworld meetings due to language, accessibility, and geographic constraints.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20200227/13673b0b/attachment.htm 


More information about the opensource-dev mailing list