[sldev] Viewer Auth Postponed

Lawson English lenglish5 at cox.net
Fri Jan 11 11:35:09 PST 2008


Tess Chu wrote:
> Yesterday afternoon several teams involved with Viewer Auth met to 
> discuss the rising number of critical login issues holding up progress 
> for the release of the 1.18.6 client.  The final decision was to 
> postpone Viewer Auth by putting back the old login code.
>
> The reasons at the forefront of this decision include:
> * Internal projects relying on viewer-auth have been delayed.
> * Problems with web servers serving the login page.
> * Unknown cause of crashes at startup.
> * LLMozlib's support of frames has caused numerous bugs.
>
> What this means for you:
> * Second Life client will default to the old login
> * There is no urgent need to support the new login mechanism in your 
> client.
> * Existing viewers built with the new login mechanism will continue to 
> function since the server component of the new mechanism will stay in 
> place.
>
> In Q1/2008, Studio Icehouse plans to begin work on Agent Domain Login 
> (https://wiki.secondlife.com/wiki/Agent_Domain#How_login_works).  When 
> we resume Viewer Auth, it will likely incorporate the interoperability 
> changes from the login protocol work being designed by the 
> Architecture Working Group. Those interested are welcome to participate.


It might be good to create a simple login stub for test purposes. When I 
was working on my Python-based micro-SLProxy code a few nights ago, I 
found that the client itself would accept the output from the 
Python-proxy, but my own Python-based login code would not. I futzed 
around with that for several hours and it suddenly started working. As 
far as I can tell, nothing I did actually made a difference: for a while 
the Python login code was incompatible while the SL Client code was not. 
Then they both worked. This was during the aftermath of some backend 
work you guys did on wednesday.

Its always possible that I did something without realizing it to make my 
code work, but I suspect that something was subtly not-kosher on the 
server end and the Client was robust to handle the issues while the Q&D 
Python login code was not.


So... a reference login server that passes back standardized test data 
might be a good thing to provide access to so we can test these new 
protocols without worrying if some  strange back-end code issue is 
causing the problem or if its our own code.


Lawson


More information about the SLDev mailing list