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