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 !
> the upcoming changes to Premium levels will require some viewer
> updates to maintain full compatibility.*
This is not just "full compatibility", because sadly, the way you (LL)
chose to implement the "benefits" rendered many old viewers incapable
of login into SL. More on that below.
> 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.
Granted, only the fixed upload cost (currently L$10 in SL) is transmitted
by the server and used by the viewers, but extending the message with
more costs (and/or changing that cost server side, based on the logged
in avatar account level) would have kept old viewers compatible with the
login process.
> that will need to be sensitive to the account type of the user. Rather
> than just telling the viewer the users’ account level (which we will
> also do) and then putting code into the viewer to adjust based on that
> type, we have built a more general solution. A new key ('benefits') in
> the LLSD map returned by login identifies a map whose keys are "benefit
> tags" and whose values are what that benefit level is for the logged-in
> user.
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).
> 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 !).
> 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.
> When can we release these changes?
>
> We strongly encourage you to integrate these changes as soon as
> possible. You are free to begin incorporating the changes and releasing
> them any time (but please watch for updates to them).
We don't have any choice, because of a poor design of the said changes.
Beside the redundant aspect (with the EconomyData message), there was
no backward compatibility guard.
Even if you want to get rid of EconomyData (even if I don't see why),
it would have been dead easy to implement the following protocol:
- on login request by the viewer, the server looks at the
requested_options map (see LLLoginInstance::constructAuthParams()).
- if the said map contains the "benefits" keyword, then the server
sends the benefits array in its reply, else it omits it.
This way, old viewers (that don't know what to do with that array) are
still able to connect, and new viewers needing that array can request
it.
> What will happen with unmodified viewers when the Premium changes go
> into effect?
>
> Most Second Life usage should be fine without the updates, but there may
> be subtle problems. For example, an unmodified viewer may have the wrong
> cost for some action; if the viewer expects the cost to be lower than
> the simulator does, the simulator will reject the request.
Which is NOT an issue for most old viewers; e.g. I was using OMV (that
just got broken), but never used paying services with it...
Another super-useful (actually pretty much *essential*) use case for
"deprecated" viewers is to find the origin of a bug: "what was the
last viewer version which did not have that bug ?" is the first question
I pose to myself whenever a regression bug is found.Was it pre-BOM, pre-
Animesh, pre-Materials, pre-whatever-shader-or-render-pipeline-change ?
As it is today, I cannot any more test old viewer versions in SL should
I have a regression to diagnose and fix ! >:-(
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 !
Shame on you, LL !
A pissed off,
Henri.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
