Difference between revisions of "SLGOGP Draft 1/Discuss 3-2 Legacy Login"
m |
(note about an corrected/formatted legacy login section) |
||
| Line 17: | Line 17: | ||
[[User:Leyla Linden|Leyla Linden]] 17:17, 26 March 2008 (PDT) | [[User:Leyla Linden|Leyla Linden]] 17:17, 26 March 2008 (PDT) | ||
I modded the [[Second_Life_Login_API_Strawman#Optional_Response]] section of the strawman API to more accurately reflect the response dump I did from my python script. Tried to put it in the format the the SLGOGP is already using so someone with editing authorization (Zero?) can just cut and paste from the more correct version to the relevant section of the SLGOGP. ```` | |||
Revision as of 12:18, 28 March 2008
| SLGOGP Draft 1 > Discuss 3-2 Legacy Login |
Legacy Login Transforms
Occasionally an agent will have one or more transforms in the database. These include things like changing estates or moving inventory that happen on login. In this case the response of legacy login will not have
{ login: true }
but will instead include
{ login: indeterminate, next_url: transform_url, next_method: transform, message: a status update }
In this case the client needs to post everything it posted to the legacy login resource to the next_url in the response. The response from that may come back as another transform or if there no more transforms left the response will include
{ login: true, next_url: login_url, next_method: login_to_simulator }
at which point the next_url will be the legacy login resource and posting to it as we did before should result in the successful legacy login resource response.
Leyla Linden 17:17, 26 March 2008 (PDT)
I modded the Second_Life_Login_API_Strawman#Optional_Response section of the strawman API to more accurately reflect the response dump I did from my python script. Tried to put it in the format the the SLGOGP is already using so someone with editing authorization (Zero?) can just cut and paste from the more correct version to the relevant section of the SLGOGP. ````