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. <https://en.wikipedia.org/wiki/Robustness_principle> Indeed. I have no commit access to OMV (which is why I forked Libremetaverse) and a lot of it hrmmmm… 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
