Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 19 Mar 2020 21:24:10 +0100, Henri Beauchamp wrote:

> On Thu, 19 Mar 2020 15:29:01 -0400, Oz Linden (Scott Lawrence) wrote:
> 
> > When I log in I get a great deal more than that.
> 
> Strange, to say the least... O.O
> 
> I got debug messages for user auth XML RPC data reply in my viewer,
> and I don't see anything else than "additional_listing_cost" and
> "num_free_listings" under "account_level_benefits"...

OK, it was a bug in the xmlrpc_type_struct processing of my viewer (only
the second level and deeper structures were properly taken into account).

Sorry for the noise !

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

Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 19 Mar 2020 21:24:10 +0100, Henri Beauchamp wrote:

> All you need to change is to add in LLLoginInstance::constructAuthParams():
> requested_options.append("agent_appearance_service");

Of course, I meant:
requested_options.append("account_level_benefits");

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

Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 19 Mar 2020 15:29:01 -0400, Oz Linden (Scott Lawrence) wrote:

> On 2020-03-19 11:58 , Henri Beauchamp wrote:
> > However, a couple of things are confusing. Would you please care to explain
> > them:
> >
> > - So far, on login, the only "account_level_benefits" parameters returned
> >by the server are: "additional_listing_cost" and "num_free_listings",
> >which are not even parsed for/used in your code !
> >No parameter dealing with upload costs, creation group cost, attachments
> >limit or picks limit, while your new code relies on them: is it normal
> >(i.e. not yet implemented server-side) or is it a problem with my SL
> >accounts (one premium and several normal/free accounts, all showing the
> >same set of "account_level_benefits" parameters, and just different
> >values) ?
> Where are you logging in? 

Anywhere in Agni or Aditi...

> When I log in I get a great deal more than that.

Strange, to say the least... O.O

I got debug messages for user auth XML RPC data reply in my viewer,
and I don't see anything else than "additional_listing_cost" and
"num_free_listings" under "account_level_benefits"...

> > - There is a "ViewerBenefits" capability requested by your new code, but
> >that capability is never used... Is it normal, or is something missing
> >there ?
> 
> That's there as a flag to inform the simulator that the viewer 
> understands the new benefits mechanism. As far as I know we have not 
> used it for anything, but it's there so that if we discover a 
> backwards-compatibility problem serious enough we can modify messaging 
> or make some other accomodation.

You won't need this "flag" with the "normal" login protocol consisting
for the viewer to request the data associated with that feature on login,
i.e. a viewer implementing or not the "benefits" feature can be flagged
as such as soon as at the login request, while the capabilities (for the
login region) are requested much latter in the login process (and need to
be re-requested at each new region connection, with potential race
condition issues during the long "connect to region" -> "wait for seed" ->
"send caps request" process).

All you need to change is to add in LLLoginInstance::constructAuthParams():
requested_options.append("agent_appearance_service");

Then, when the login server receives the above option request, it flags
the agent/viewer as benefits-aware (no need any more for the unused
capability) and sends the corresponding parameters (and by not sending
them when not requested, you also restore the login compatibility with
old viewers).

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

Re: [opensource-dev] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

On 2020-03-19 11:58 , Henri Beauchamp wrote:

However, a couple of things are confusing. Would you please care to explain
them:

- So far, on login, the only "account_level_benefits" parameters returned
   by the server are: "additional_listing_cost" and "num_free_listings",
   which are not even parsed for/used in your code !
   No parameter dealing with upload costs, creation group cost, attachments
   limit or picks limit, while your new code relies on them: is it normal
   (i.e. not yet implemented server-side) or is it a problem with my SL
   accounts (one premium and several normal/free accounts, all showing the
   same set of "account_level_benefits" parameters, and just different
   values) ?

Where are you logging in?  When I log in I get a great deal more than that.

- There is a "ViewerBenefits" capability requested by your new code, but
   that capability is never used... Is it normal, or is something missing
   there ?


That's there as a flag to inform the simulator that the viewer 
understands the new benefits mechanism. As far as I know we have not 
used it for anything, but it's there so that if we discover a 
backwards-compatibility problem serious enough we can modify messaging 
or make some other accomodation.


--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com  | Scott Lawrence 


LINDEN LAB | Create Virtual Experiences 
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 19 Mar 2020 10:46:27 -0400, Oz Linden (Scott Lawrence) wrote:

> The DRTVWR-481 branch has been promoted to the default viewer and pulled 
> to the master branch.

Sadly, there is no corresponding commit to be found: the only commit 
between the master branch and DRTVWR-481 (which is now gone and cannot
be browsed any more) is the opposite one, i.e. the merge of the release
viewer branch into DRTVWR-481, prior to the promotion of the latter...

So, I downloaded a diffed the master and the v6.3.8 release tags to diff
them but, surprise, they only differ by their version number (only one
diff in the sources, dealing with the version increment from 6.3.8 to
6.3.9) !

In fact, to get the full batch of changes between the former release
tag and the merged DRTVWR-481 branch, I has to diff the sources for
the release tags of 6.3.7 and 6.3.8...

What a mess !


> TPVs will save their users confusion and reduce support questions by 
> getting as many users as possible onto viewers with this support by the 
> time we change the Premium offerings. I don't have a target date for it 
> I can share, but it's not that far off.

I already implemented most of the changes (in my own way, to keep things
OpenSim-compatible, i.e. keeping also the old economy-based process), and
did not find much added changes in the new diff.

However, a couple of things are confusing. Would you please care to explain
them:

- So far, on login, the only "account_level_benefits" parameters returned
  by the server are: "additional_listing_cost" and "num_free_listings",
  which are not even parsed for/used in your code !
  No parameter dealing with upload costs, creation group cost, attachments
  limit or picks limit, while your new code relies on them: is it normal
  (i.e. not yet implemented server-side) or is it a problem with my SL
  accounts (one premium and several normal/free accounts, all showing the
  same set of "account_level_benefits" parameters, and just different
  values) ?

- There is a "ViewerBenefits" capability requested by your new code, but
  that capability is never used... Is it normal, or is something missing
  there ?

Regards,

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

Re: [opensource-dev] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

The DRTVWR-481 branch has been promoted to the default viewer and pulled 
to the master branch.


TPVs will save their users confusion and reduce support questions by 
getting as many users as possible onto viewers with this support by the 
time we change the Premium offerings. I don't have a target date for it 
I can share, but it's not that far off.



**

*As we mentioned at the last Third Party Viewer meeting, the upcoming 
changes to Premium levels will require some viewer updates to maintain 
full compatibility.*


*

Why are there changes?

The viewer currently has some messages and costs hard coded 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.


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.


Where are the changes?

The changes are in the 'DRTVWR-481 
' branch in 
the viewer git repository. A viewer built from that branch will be 
available as a Release Candidate soon.


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


The login servers should already be returning the benefits information 
(the values are the same as those currently in the viewer; they'll 
change when we make the new Premium Plus level available and introduce 
other changes to Premium).


The simulator support for benefits is still being finalized and 
deployed; they are just beginning to use the benefits information from 
login in the same way this new viewer branch does. In practice, both 
should arrive at the same numbers since the current benefits 
information from login matches the old hard coded values. If your 
testing shows any discrepancies, please report them via Jira as 
quickly as possible.


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.


*



--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com  | Scott Lawrence 


LINDEN LAB | Create Virtual Experiences 
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Cinder Roxley]

On February 27, 2020 at 10:10:28 AM, Oz Linden (Scott Lawrence) (
o...@lindenlab.com) wrote:

On 2020-02-27 08:21 , Cinder Roxley wrote:

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

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

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.

Understood. Naturally, the onus for compatibility is on the client
developer. In this case, the failure happened because the XmlRpc library
being utilized is poor quality… most C# XmlRpc libraries are. This has been
remedied in LibreMetaverse/Radegast. I had only wanted to mention advanced
warning is appreciated because these “rouge” implementations do exist and
people use them to connect.

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 by Postel's Law.


Indeed. I have no commit access to OMV (which is why I forked
Libremetaverse) and a lot of it hr… questionable to say the least. :)

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.

Thanks kindly, Oz. I do appreciate the notice and communication you and the
rest of the lab have and do provide via this list, open e-mail inboxes,
meetings, and wiki articles. It’s a lot more developer support than I’ve
had from Mojang and other companies writing third party addons and I don’t
take that for granted.
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[hw]

So after stealing my money you make stuff more expensive for everyone and try 
to either get rid of the users that aren't signed up or force them to sign up 
so that you can steal their money, too.

How about you finally fix other problems like the block list not being loaded 
and making use of graphics cards that aren't a decade old first?


On Tuesday, February 25, 2020 4:48:03 PM CET Oz Linden (Scott Lawrence) wrote:
> **
> 
> *As we mentioned at the last Third Party Viewer meeting, the upcoming
> changes to Premium levels will require some viewer updates to maintain
> full compatibility.*
> 
> *
> 
> Why are there changes?
> 
> The viewer currently has some messages and costs hard coded 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.
> 
> 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.
> 
> Where are the changes?
> 
> The changes are in the 'DRTVWR-481
> ' branch in
> the viewer git repository. A viewer built from that branch will be
> available as a Release Candidate soon.
> 
> 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).
> 
> The login servers should already be returning the benefits information
> (the values are the same as those currently in the viewer; they'll
> change when we make the new Premium Plus level available and introduce
> other changes to Premium).
> 
> The simulator support for benefits is still being finalized and
> deployed; they are just beginning to use the benefits information from
> login in the same way this new viewer branch does. In practice, both
> should arrive at the same numbers since the current benefits information
> from login matches the old hard coded values. If your testing shows any
> discrepancies, please report them via Jira as quickly as possible.
> 
> 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.
> 
> *




___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 27 Feb 2020 12:44:31 -0800, Brian McGroarty wrote:

> All else aside: In the future, if you notice something on aditi adversely
> affects your viewer, please don't be shy about raising it on this list or
> in a JIRA. An early heads up may be helpful to other viewer devs, or it
> will make it more feasible for the company to alter or postpone a change.

Frankly, given the data that was transmitted on login on Aditi in the
additional parameters (just a few meaningless strings, including a couple
in Russian), I thought it was just a test for some more serious,
to-be-announced-and-properly-QAed change that would be implemented later
on...

There was also, no trace of changes to the login parameters in the
viewer(s) code on LL's git repository (no new viewer branch announced
either, that would use those new parameters).

I won't have imagined that such an essential component as the login server
would see its protocol modified on Agni so stealthily and quickly, without
even *some* forewarning... O.O

Now, I know by experience this actually can happen ! :-/

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

Re: [opensource-dev] Viewer changes for Premium changes

[Brian McGroarty]

On Tue, Feb 25, 2020 at 12:17 PM Henri Beauchamp  wrote:

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

All else aside: In the future, if you notice something on aditi adversely
affects your viewer, please don't be shy about raising it on this list or
in a JIRA. An early heads up may be helpful to other viewer devs, or it
will make it more feasible for the company to alter or postpone a change.
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 27 Feb 2020 14:39:10 -0500, Oz Linden (Scott Lawrence) wrote:

> That protocol works (and from time to time we employ it) when the change 
> is one that can be compatible, but that's not the case here. The account 
> levels are not an optional thing, and there never was any way we could 
> maintain backward compatibility on the server for viewers that don't get it.

You said yourself that:
"
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.
"

I see no mandatory change there, and no breakage in SL server side, so
no risk whatsoever for the grid or its services... At worst, the old
viewers will not be able to upload assets.

Beside, as I already explained:

"
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 ?
"

For the above use cases, there is no issue whatsoever when the viewer
does not know about the account level !


> The fact that some incomplete XMLRPC implementations not based on ours

LOL 

Too bad for you: the implementation I used was the one LL wrote for v1
viewers !

So, that's *your* code, not mine !

Beside, the implementation was "complete" (and worked for over 14 years)
for the parameters that were in use till you implemented that change
without even letting us, TPV developers, test it and give feed back.

Instead of apologizing properly and fixing the login server code to
*NOT* send the extra info when not requested, you keep trying to find
excuses and specious, illogical reasons to justify your failure.

So lame...

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

Re: [opensource-dev] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

On 2020-02-27 12:37 , Henri Beauchamp wrote:

2.- Had you*simply*  (this is really trivial, since this is how the
 viewers and login server already work !) respected the normal
 protocol, not sending any "account_level_benefits" related info
 to the viewers not requesting that option on login, there would
 not have been*any*  problem !

 NOTE THAT IT IS NOT TOO LATE: you could*still*  modify the login
 server code to comply with the list of the requested options and
 stop sending the "account_level_benefits" stuff when not requested.
 This would*instantly*  restore the compatibility with the old
 viewers, and all you would have to change in the new viewer code
 is to add:
requested_options.append("account_level_benefits");
 in LLLoginInstance::constructAuthParams()


That protocol works (and from time to time we employ it) when the change 
is one that can be compatible, but that's not the case here. The account 
levels are not an optional thing, and there never was any way we could 
maintain backward compatibility on the server for viewers that don't get it.


The fact that some incomplete XMLRPC implementations not based on ours 
failed when they shouldn't have isn't something we could have 
anticipated or done anything about.


--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com  | Scott Lawrence 


LINDEN LAB | Create Virtual Experiences 
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

On Thu, 27 Feb 2020 11:10:19 -0500, Oz Linden (Scott Lawrence) wrote:

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

1.- To be more precise, the issue is not even about an array in a LLSD,
but about a "structure" (xmlrpc_type_struct) in the XML RPC reply.
Such structures were never used before and therefore the code for
dealing with them was never implemented in many viewers (this got
implemented sometime in LL's v3 code, which did not need to be
backported back then since the said code was unused).
So, it's not about a flawed or deprecated implementation from the
viewer developers' part, but just about a new type of parameter
passed on login, that was not expected by them !

2.- Had you *simply* (this is really trivial, since this is how the
viewers and login server already work !) respected the normal
protocol, not sending any "account_level_benefits" related info
to the viewers not requesting that option on login, there would
not have been *any* problem !

NOTE THAT IT IS NOT TOO LATE: you could *still* modify the login
server code to comply with the list of the requested options and
stop sending the "account_level_benefits" stuff when not requested.
This would *instantly* restore the compatibility with the old
viewers, and all you would have to change in the new viewer code
is to add:
requested_options.append("account_level_benefits");
in LLLoginInstance::constructAuthParams()


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

The simple fact of announcing the change (and explaining it) in Aditi
after it was done and asking for testing and feedback would have
avoided the entire mess...

Draw your own conclusions about LL's communication and QA processes,
but I'd personally say, based on observation of the result, that they
are flawed.


And by the way:


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

> The changes are in the 'DRTVWR-481 
> ' branch in 
> the viewer git repository.
> .../...
> 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).

Too bad... The only parameters currently sent in Agni by the login
server are "additional_listing_cost" and "num_free_listings", and nothing
else (in particular, no upload cost, no max group membership). So, should
someone backport the changes as currently implemented in the repository
you point at (i.e with the LLGlobalEconomy removed), they would end up
with a non-functionnal viewer in SL !

'nuff said !

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

Re: [opensource-dev] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

On 2020-02-27 11:26 , Nathaniel Prugh wrote:


Can you show me the links to announcement of new premium. Features 
like the plus?


We have not yet announced the specific changes, just that some are 
coming including the new Premium Plus level.  Those should be coming 
pretty soon, but a search at https://community.secondlife.com/blogs will 
find many references.


--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com  | Scott Lawrence 


LINDEN LAB | Create Virtual Experiences 
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Nathaniel Prugh]

Sent from my iPhone

On Feb 27, 2020, at 8:14 AM, Oz Linden (Scott Lawrence)  
wrote:


On 2020-02-25 16:10 , Nathaniel Prugh wrote:
Where is announcement of those features in sl blog? So we know what new stuff 
coming soon etc?

[..]

The fact that we're making changes to Premium and introducing a new Premium 
Plus upgrade has been extensively discussed on the blogs for months.

Hey oz...

Can you show me the links to announcement of new premium. Features like the 
plus?

Thanks again.


___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Oz Linden (Scott Lawrence)]

On 2020-02-25 16:10 , Nathaniel Prugh wrote:
Where is announcement of those features in sl blog? So we know what 
new stuff coming soon etc?


We don't normally use the blogs for communicating code changes; that's 
what this list is for.


The fact that we're making changes to Premium and introducing a new 
Premium Plus upgrade has been extensively discussed on the blogs for months.


--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com  | Scott Lawrence 


LINDEN LAB | Create Virtual Experiences 
___
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

Re: [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 (sl...@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
> ' 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. 



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: o...@lindenlab.com  | Scott Lawrence 


LINDEN LAB | Create Virtual Experiences 
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Cinder Roxley]

On February 25, 2020 at 2:17:16 PM, Henri Beauchamp (sl...@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
> ' 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.
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Nathaniel Prugh]

Where is announcement of those features in sl blog? So we know what new stuff 
coming soon etc?

Sent from my iPhone

On Feb 25, 2020, at 7:48 AM, Oz Linden (Scott Lawrence)  
wrote:



As we mentioned at the last Third Party Viewer meeting, the upcoming changes to 
Premium levels will require some viewer updates to maintain full compatibility.

Why are there changes?

The viewer currently has some messages and costs hard coded 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.

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.

Where are the changes?

The changes are in the 
'DRTVWR-481'
 branch in the viewer git repository. A viewer built from that branch will be 
available as a Release Candidate soon.

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

The login servers should already be returning the benefits information (the 
values are the same as those currently in the viewer; they'll change when we 
make the new Premium Plus level available and introduce other changes to 
Premium).

The simulator support for benefits is still being finalized and deployed; they 
are just beginning to use the benefits information from login in the same way 
this new viewer branch does. In practice, both should arrive at the same 
numbers since the current benefits information from login matches the old hard 
coded values. If your testing shows any discrepancies, please report them via 
Jira as quickly as possible.

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.

--
OZ LINDEN | VP Second Life Engineering
email: o...@lindenlab.com | Scott 
Lawrence
LINDEN LAB | Create Virtual 
Experiences
___
Policies and (un)subscribe information available here:
https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwiki.secondlife.com%2Fwiki%2FOpenSource-Devdata=02%7C01%7Cnathaniel.prugh%40bellevuecollege.edu%7C942e75979c6042d528a608d7ba0a21da%7Cf94c251c1347422eb3ea8ac56befd6cb%7C0%7C0%7C637182424989505340sdata=cS4bbvJPjDkQOOi2cpqMyPXhNGLCPK5qJj3egwMr12c%3Dreserved=0
Please read the policies before posting to keep unmoderated posting privileges
___
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

Re: [opensource-dev] Viewer changes for Premium changes

[Henri Beauchamp]

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