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 
> <https://bitbucket.org/lindenlab/viewer/branch/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

Reply via email to