Second Life Wiki - User contributions [en]

LLQtWebKit Win32 Build Instructions

2010-04-21T23:26:59Z

Leyla Linden: /* Win32GL */

<<< [https://wiki.secondlife.com/wiki/LLQtWebKit Back to LLQtWebKit main page]

== Introduction ==
These are instructions for building the Qt/WebKit library (LLQtWebKit) on Windows as well as the test applications (testGL, uBrowser, QtTestApp, Win32GL). They have been tested using Microsoft Visual Studio 2005 (SP2) on Windows XP Service Pack 3 and Qt 4.6.0. It is not known if the same instructions work using other versions of Windows, Microsoft Visual Studio or Qt.

== Set up ==
* For clarity, these instructions contain references to example paths and directories. Except where noted, you may replace these with ones of your own choosing although it is generally advisable to choose ones without spaces in them.

== Acquire LLQtWebKit source code ==
* In a Web browser, navigate to http://hg.secondlife.com/llqtwebkit/
* Select "get source->zip" from menu
* A zip file of the source code will be downloaded
* Extract the contents of the zip file to <code>C:\llqtwebkit</code>
**Note: Different archiving tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\llqtwebkit</code> and not <code>C:\llqtwebkit\llqtwebkit</code>

== Build the open source OpenSSL library ==
* Make sure a recent version of '<code>perl</code>' and '<code>patch</code>' are available on your system.
* Download the OpenSSL 0.9.8l tarball from http://openssl.org/source/openssl-0.9.8l.tar.gz
* Extract the contents to <code>C:\openssl-0.9.8l</code>
** Note: Different archive tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\openssl-0.9.8l</code> and not <code>C:\openssl-0.9.8l\openssl-0.9.8l</code>
** Note: Some archive tools (notably 7-Zip) appear to have issues extracting the files correctly - make sure the header files in the <code>C:\openssl-0.9.8l\include\openssl</code> directory are not zero length before proceeding.
* Open the "Visual Studio 2005 Command Prompt" (Start Menu->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt)
* Change to the <code>C:\openssl-0.9.8l</code> directory
* Run these commands:
** <code>perl Configure VC-WIN32</code>
** <code>ms\do_masm</code>
* Patch the <code>ntdll.mak</code> file generated by the previous steps (this fixes the DLL manifest settings so that they are compatible with the Second Life client build configuration)
** Copy the patch file <code>020-openssl-disable-manifest.patch</code> from the <code>C:\llqtwebkit-4.6\patches</code> to <code>C:\openssl-0.9.8l</code>
** Run this command:
*** <code>patch -p1 < 020-openssl-disable-manifest.patch</code>
* Continue to build
** <code>nmake -f ms\ntdll.mak</code>
* After a few minutes, the libraries <code>libeay32.dll</code> and <code>ssleay32.dll</code> will be built in the <code>C:\openssl-0.9.8l\out32dll</code> directory - confirm they exist - they will be needed later.

== Build the open source version of Qt 4.6.0 using Microsoft Visual Studio ==
=== Acquire the Qt 4.6.0 source with our patches ===
* Our clone of Qt is available here: http://gitorious.org/+lindenqt/qt/lindenqt
* Download the source by clicking on the "lindenqt" branch under "Branches:" and then using the "Download lindenqt as tar.gz" link on the right hand side of the page
** It's a large download - over 100MB - so it may take some time
** Alternately, if you prefer you can clone the repository with git using the "clone" link on the page -- details of this are left as an exercise to the reader
* Extract the contents of the tarball into <code>C:\qt-lindenqt</code>
* This may take some as the archive contains a lot of files
** Note: Different tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\qt-lindenqt</code> and not <code>C:\qt-lindenqt\qt-lindenqt</code>
** Note: using Cygwin's <code>tar</code> command might not work. It may result in an '''Access is Denied''' error when running configure below. If so, try using WinZip, WinRAR or some other tool instead.

=== Configure Qt ===
* If it's not open already, open the "Visual Studio 2005 Command Prompt" (Start Menu->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt)
* Change to the <code>C:\qt-lindenqt</code> directory
* Run this command:
<code>configure -debug-and-release -no-qt3support -no-phonon -no-phonon-backend -prefix C:\qt-lindenqt -qt-libjpeg -qt-libpng -openssl-linked -I C:\openssl-0.9.8l\include -L C:\openssl-0.9.8l\out32dll</code>
* When you are asked if you want to use the Commercial or Open Source version type <code>o</code> to select Open Source and press the Enter key
* When the license agreement appears, if you agree type <code>y</code> the Enter key
* This operation takes around 10-15 minutes on a typical development system

=== Build Qt ===
* Change to the <code>C:\qt-lindenqt</code> directory
* Run this command:
<code>nmake sub-src</code>
* This operation takes around 1-2 hours on a typical development system
* After building Qt, the release and debug libraries and dlls will be in <code>C:\qt-lindenqt\lib</code>

=== Configure a Qt runtime environment ===
* Copy the OpenSSL dynamic libraries (<code>C:\openssl-0.9.8l\out32dll\libeay32.dll</code> and <code>C:\openssl-0.9.8l\out32dll\ssleay32.dll</code>) to the Qt binary directory (<code>C:\qt-lindenqt\bin</code>)
* Create the file <code>C:\qt-lindenqt\bin\qt-vars.bat</code> and put the following in it:
@echo off
echo Setting up a Qt environment...
set QTDIR=C:\qt-lindenqt
set PATH=C:\qt-lindenqt\bin;%PATH%
set QMAKESPEC=win32-msvc2005
call "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"
* Make a shortcut to <code>qt-vars.bat</code> on your desktop
* Right-click on the shortcut and set the following properties:
Target: %COMSPEC% /k "C:\qt-lindenqt\bin\qt-vars.bat"
Start in: C:\qt-lindenqt
* Rename the shortcut to "Qt Linden Command Prompt".
* Test it by opening the prompt and typing
qmake --version
* Confirm that the Qt version displayed is 4.6.0

== Build LLQtWebKit ==
* Launch the Qt command prompt and enter the following in the command prompt:
cd C:\llqtwebkit
qmake CONFIG-=debug
nmake
* This operation takes just a few seconds on a typical development system
* If you want to build the debug version of LLQtWebKit, use <code>qmake CONFIG+=debug</code> instead
* Now LLQtWebKit is built and can be used in the Second Life viewer.
* If you want to build the test applications, follow the next steps:

== Acquire test application dependencies ==
=== Glut ===
* Glut is a cross-platform library that manages OpenGL state and creation/destruction of OpenGL windows
* The author provides a library and header for Windows so you do not have to build them yourself
* Download the library and headers from http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip
* Extract the contents of the zip to a new folder called <code>C:\llqtwebkit\tests\GL</code>

=== GLUI ===
* Glut is a cross-platform library that renders UI components in the uBrowser test application
* The author does not provide libraries for Windows so you have to build them yourself.
* Download the source code from http://sourceforge.net/projects/glui/files/Source/2.36/glui-2.36.zip/download
* Extract to <code>C:\glui-2.36</code>
* Copy <code>glut.h</code> from <code>C:\llqtwebkit\tests\GL</code> to <code>C:\glui-2.36\src\include\GL</code> as it is required to build GLUI
* Open <code>C:\glui-2.36\src\msvc\glui.sln</code> and let Visual Studio convert the project
* Select "Release" configuration of "_glui library" project and build it as normal
* Copy the GLUI header (<code>C:\glui-2.36\src\include\GL\glui.h</code>) to <code>C:\llqtwebkit\tests\GL</code>
* Copy the GLUI library you just built (<code>C:\glui-2.36\src\msvc\lib\glui32.lib</code>) to <code>C:\llqtwebkit\tests\GL</code>

== Build test applications ==
=== testGL ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\testgl
qmake CONFIG-=debug
nmake
..\GL\testgl.exe
* If you want to build the debug version, use <code>qmake CONFIG+=debug</code> instead and run <code>nmake clean</code> first

=== uBrowser ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\ubrowser
qmake CONFIG-=debug
nmake
..\GL\ubrowser.exe
* Important: <code>glui.h</code> contains a pragma that forces the build to always link against the release version - <code>glut32.lib</code> - instead of the debug version. This means building a debug version of uBrowser is currently broken.

=== QtTestApp ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\qttestapp
qmake CONFIG-=debug
nmake
..\GL\qttestapp.exe
* If you want to build the debug version, use <code>qmake CONFIG+=debug</code> instead and run <code>nmake clean</code> first

=== Win32GL ===
* Edit the path variables at the top of the <code>C:\llqtwebkit\tests\win32gl\copy_files.bat</code> directory to reflect the location of your OpenSSL, Qt and LLQtWebKit files.
* Run the <code>C:\llqtwebkit\tests\win32gl\copy_files.bat</code>
* Open the <code>C:\llqtwebkit\tests\win32gl\win32gl.sln</code> MSVC solution file
* Select <code>Release</code> configuration
* Update <code>home_url</code> in win32gl.cpp with the correct path to your testpage
* Build and run as normal

== Win32 Helper batch files ==
* There are some helper batch files for Windows developers that may prove useful.
* You will very likely need to configure settings at the top of each one to match the location of the files and directories on your system.
* They do not do much error checking so make sure you understand the ramifications of any changes you make.
* A useful pattern is to edit them so they only do what you need at that moment - build release LLQtWebKit and testGL for example - then revert them when you're finished.

=== Build LLQtWebKit and test apps ===
* Now you have built LLQtWebKit by hand, I'll point out this batch file which does it for you.
* <code>C:\llqtwebkit\make_all.bat</code> is a very simple batch file that will clean and build release and debug versions of LLQtWebKit and then clean and build release version of the test apps (except Win32GL).
* You will need to modify the GL_COMPONENT_DIR variable near the top that sets the location of the GLUT and GLUI build files.
* You almost certainly will want to run this batch file from a Qt command prompt as described above since various Qt directories need to be in the path.

=== Generate a directory tree compatible with the Second Life client build system ===
* <code>C:\llqtwebkit\copy_llqtwebkit.bat</code> is a batch file that:
** Generates a directory tree containing LLQtWebKit header and libraries along with the necessary Qt run time files that are required by the Second Life client.
** Builds a <code>tar.bz2 </code> archive and associated MD5 sum that can be used in the LLQtWebKit section of the Second Life client <code>install.xml</code> configuration file.

== Notes ==
* To enable a run time console for the test applications add a <code>CONFIG+=console</code> line to the <code>qmake </code> line.
* Make sure all libraries and applications are built as Multi-threaded Dll or Multi-threaded debug dll. In Visual Studio this is in Properties->configuration->c/c++->code generation->runtime library
* Make sure you do not mix release and debug versions of libraries and applications

LLQtWebKit Win32 Build Instructions

2010-04-21T23:26:45Z

Leyla Linden: /* Win32GL */

<<< [https://wiki.secondlife.com/wiki/LLQtWebKit Back to LLQtWebKit main page]

== Introduction ==
These are instructions for building the Qt/WebKit library (LLQtWebKit) on Windows as well as the test applications (testGL, uBrowser, QtTestApp, Win32GL). They have been tested using Microsoft Visual Studio 2005 (SP2) on Windows XP Service Pack 3 and Qt 4.6.0. It is not known if the same instructions work using other versions of Windows, Microsoft Visual Studio or Qt.

== Set up ==
* For clarity, these instructions contain references to example paths and directories. Except where noted, you may replace these with ones of your own choosing although it is generally advisable to choose ones without spaces in them.

== Acquire LLQtWebKit source code ==
* In a Web browser, navigate to http://hg.secondlife.com/llqtwebkit/
* Select "get source->zip" from menu
* A zip file of the source code will be downloaded
* Extract the contents of the zip file to <code>C:\llqtwebkit</code>
**Note: Different archiving tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\llqtwebkit</code> and not <code>C:\llqtwebkit\llqtwebkit</code>

== Build the open source OpenSSL library ==
* Make sure a recent version of '<code>perl</code>' and '<code>patch</code>' are available on your system.
* Download the OpenSSL 0.9.8l tarball from http://openssl.org/source/openssl-0.9.8l.tar.gz
* Extract the contents to <code>C:\openssl-0.9.8l</code>
** Note: Different archive tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\openssl-0.9.8l</code> and not <code>C:\openssl-0.9.8l\openssl-0.9.8l</code>
** Note: Some archive tools (notably 7-Zip) appear to have issues extracting the files correctly - make sure the header files in the <code>C:\openssl-0.9.8l\include\openssl</code> directory are not zero length before proceeding.
* Open the "Visual Studio 2005 Command Prompt" (Start Menu->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt)
* Change to the <code>C:\openssl-0.9.8l</code> directory
* Run these commands:
** <code>perl Configure VC-WIN32</code>
** <code>ms\do_masm</code>
* Patch the <code>ntdll.mak</code> file generated by the previous steps (this fixes the DLL manifest settings so that they are compatible with the Second Life client build configuration)
** Copy the patch file <code>020-openssl-disable-manifest.patch</code> from the <code>C:\llqtwebkit-4.6\patches</code> to <code>C:\openssl-0.9.8l</code>
** Run this command:
*** <code>patch -p1 < 020-openssl-disable-manifest.patch</code>
* Continue to build
** <code>nmake -f ms\ntdll.mak</code>
* After a few minutes, the libraries <code>libeay32.dll</code> and <code>ssleay32.dll</code> will be built in the <code>C:\openssl-0.9.8l\out32dll</code> directory - confirm they exist - they will be needed later.

== Build the open source version of Qt 4.6.0 using Microsoft Visual Studio ==
=== Acquire the Qt 4.6.0 source with our patches ===
* Our clone of Qt is available here: http://gitorious.org/+lindenqt/qt/lindenqt
* Download the source by clicking on the "lindenqt" branch under "Branches:" and then using the "Download lindenqt as tar.gz" link on the right hand side of the page
** It's a large download - over 100MB - so it may take some time
** Alternately, if you prefer you can clone the repository with git using the "clone" link on the page -- details of this are left as an exercise to the reader
* Extract the contents of the tarball into <code>C:\qt-lindenqt</code>
* This may take some as the archive contains a lot of files
** Note: Different tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\qt-lindenqt</code> and not <code>C:\qt-lindenqt\qt-lindenqt</code>
** Note: using Cygwin's <code>tar</code> command might not work. It may result in an '''Access is Denied''' error when running configure below. If so, try using WinZip, WinRAR or some other tool instead.

=== Configure Qt ===
* If it's not open already, open the "Visual Studio 2005 Command Prompt" (Start Menu->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt)
* Change to the <code>C:\qt-lindenqt</code> directory
* Run this command:
<code>configure -debug-and-release -no-qt3support -no-phonon -no-phonon-backend -prefix C:\qt-lindenqt -qt-libjpeg -qt-libpng -openssl-linked -I C:\openssl-0.9.8l\include -L C:\openssl-0.9.8l\out32dll</code>
* When you are asked if you want to use the Commercial or Open Source version type <code>o</code> to select Open Source and press the Enter key
* When the license agreement appears, if you agree type <code>y</code> the Enter key
* This operation takes around 10-15 minutes on a typical development system

=== Build Qt ===
* Change to the <code>C:\qt-lindenqt</code> directory
* Run this command:
<code>nmake sub-src</code>
* This operation takes around 1-2 hours on a typical development system
* After building Qt, the release and debug libraries and dlls will be in <code>C:\qt-lindenqt\lib</code>

=== Configure a Qt runtime environment ===
* Copy the OpenSSL dynamic libraries (<code>C:\openssl-0.9.8l\out32dll\libeay32.dll</code> and <code>C:\openssl-0.9.8l\out32dll\ssleay32.dll</code>) to the Qt binary directory (<code>C:\qt-lindenqt\bin</code>)
* Create the file <code>C:\qt-lindenqt\bin\qt-vars.bat</code> and put the following in it:
@echo off
echo Setting up a Qt environment...
set QTDIR=C:\qt-lindenqt
set PATH=C:\qt-lindenqt\bin;%PATH%
set QMAKESPEC=win32-msvc2005
call "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"
* Make a shortcut to <code>qt-vars.bat</code> on your desktop
* Right-click on the shortcut and set the following properties:
Target: %COMSPEC% /k "C:\qt-lindenqt\bin\qt-vars.bat"
Start in: C:\qt-lindenqt
* Rename the shortcut to "Qt Linden Command Prompt".
* Test it by opening the prompt and typing
qmake --version
* Confirm that the Qt version displayed is 4.6.0

== Build LLQtWebKit ==
* Launch the Qt command prompt and enter the following in the command prompt:
cd C:\llqtwebkit
qmake CONFIG-=debug
nmake
* This operation takes just a few seconds on a typical development system
* If you want to build the debug version of LLQtWebKit, use <code>qmake CONFIG+=debug</code> instead
* Now LLQtWebKit is built and can be used in the Second Life viewer.
* If you want to build the test applications, follow the next steps:

== Acquire test application dependencies ==
=== Glut ===
* Glut is a cross-platform library that manages OpenGL state and creation/destruction of OpenGL windows
* The author provides a library and header for Windows so you do not have to build them yourself
* Download the library and headers from http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip
* Extract the contents of the zip to a new folder called <code>C:\llqtwebkit\tests\GL</code>

=== GLUI ===
* Glut is a cross-platform library that renders UI components in the uBrowser test application
* The author does not provide libraries for Windows so you have to build them yourself.
* Download the source code from http://sourceforge.net/projects/glui/files/Source/2.36/glui-2.36.zip/download
* Extract to <code>C:\glui-2.36</code>
* Copy <code>glut.h</code> from <code>C:\llqtwebkit\tests\GL</code> to <code>C:\glui-2.36\src\include\GL</code> as it is required to build GLUI
* Open <code>C:\glui-2.36\src\msvc\glui.sln</code> and let Visual Studio convert the project
* Select "Release" configuration of "_glui library" project and build it as normal
* Copy the GLUI header (<code>C:\glui-2.36\src\include\GL\glui.h</code>) to <code>C:\llqtwebkit\tests\GL</code>
* Copy the GLUI library you just built (<code>C:\glui-2.36\src\msvc\lib\glui32.lib</code>) to <code>C:\llqtwebkit\tests\GL</code>

== Build test applications ==
=== testGL ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\testgl
qmake CONFIG-=debug
nmake
..\GL\testgl.exe
* If you want to build the debug version, use <code>qmake CONFIG+=debug</code> instead and run <code>nmake clean</code> first

=== uBrowser ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\ubrowser
qmake CONFIG-=debug
nmake
..\GL\ubrowser.exe
* Important: <code>glui.h</code> contains a pragma that forces the build to always link against the release version - <code>glut32.lib</code> - instead of the debug version. This means building a debug version of uBrowser is currently broken.

=== QtTestApp ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\qttestapp
qmake CONFIG-=debug
nmake
..\GL\qttestapp.exe
* If you want to build the debug version, use <code>qmake CONFIG+=debug</code> instead and run <code>nmake clean</code> first

=== Win32GL ===
* Edit the path variables at the top of the <code>C:\llqtwebkit\tests\win32gl\copy_files.bat</code> directory to reflect the location of your OpenSSL, Qt and LLQtWebKit files.
* Run the <code>C:\llqtwebkit\tests\win32gl\copy_files.bat</code>
* Open the <code>C:\llqtwebkit\tests\win32gl\win32gl.sln</code> MSVC solution file
* Select <code>Release</code> configuration
* Update <code>home_url<code> in win32gl.cpp with the correct path to your testpage
* Build and run as normal

== Win32 Helper batch files ==
* There are some helper batch files for Windows developers that may prove useful.
* You will very likely need to configure settings at the top of each one to match the location of the files and directories on your system.
* They do not do much error checking so make sure you understand the ramifications of any changes you make.
* A useful pattern is to edit them so they only do what you need at that moment - build release LLQtWebKit and testGL for example - then revert them when you're finished.

=== Build LLQtWebKit and test apps ===
* Now you have built LLQtWebKit by hand, I'll point out this batch file which does it for you.
* <code>C:\llqtwebkit\make_all.bat</code> is a very simple batch file that will clean and build release and debug versions of LLQtWebKit and then clean and build release version of the test apps (except Win32GL).
* You will need to modify the GL_COMPONENT_DIR variable near the top that sets the location of the GLUT and GLUI build files.
* You almost certainly will want to run this batch file from a Qt command prompt as described above since various Qt directories need to be in the path.

=== Generate a directory tree compatible with the Second Life client build system ===
* <code>C:\llqtwebkit\copy_llqtwebkit.bat</code> is a batch file that:
** Generates a directory tree containing LLQtWebKit header and libraries along with the necessary Qt run time files that are required by the Second Life client.
** Builds a <code>tar.bz2 </code> archive and associated MD5 sum that can be used in the LLQtWebKit section of the Second Life client <code>install.xml</code> configuration file.

== Notes ==
* To enable a run time console for the test applications add a <code>CONFIG+=console</code> line to the <code>qmake </code> line.
* Make sure all libraries and applications are built as Multi-threaded Dll or Multi-threaded debug dll. In Visual Studio this is in Properties->configuration->c/c++->code generation->runtime library
* Make sure you do not mix release and debug versions of libraries and applications

LLQtWebKit Win32 Build Instructions

2010-04-20T22:26:10Z

Leyla Linden: /* Build the open source OpenSSL library */

<<< [https://wiki.secondlife.com/wiki/LLQtWebKit Back to LLQtWebKit main page]

== Introduction ==
These are instructions for building the Qt/WebKit library (LLQtWebKit) on Windows as well as the test applications (testGL, uBrowser, QtTestApp, Win32GL). They have been tested using Microsoft Visual Studio 2005 (SP2) on Windows XP Service Pack 3 and Qt 4.6.0. It is not known if the same instructions work using other versions of Windows, Microsoft Visual Studio or Qt.

== Set up ==
* For clarity, these instructions contain references to example paths and directories. Except where noted, you may replace these with ones of your own choosing although it is generally advisable to choose ones without spaces in them.

== Acquire LLQtWebKit source code ==
* In a Web browser, navigate to http://hg.secondlife.com/llqtwebkit/
* Select "get source->zip" from menu
* A zip file of the source code will be downloaded
* Extract the contents of the zip file to <code>C:\llqtwebkit</code>
**Note: Different archiving tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\llqtwebkit</code> and not <code>C:\llqtwebkit\llqtwebkit</code>

== Build the open source OpenSSL library ==
* Make sure a recent version of '<code>perl</code>' and '<code>patch</code>' are available on your system.
* Download the OpenSSL 0.9.8l tarball from http://openssl.org/source/openssl-0.9.8l.tar.gz
* Extract the contents to <code>C:\openssl-0.9.8l</code>
** Note: Different archive tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\openssl-0.9.8l</code> and not <code>C:\openssl-0.9.8l\openssl-0.9.8l</code>
* Open the "Visual Studio 2005 Command Prompt" (Start Menu->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt)
* Change to the <code>C:\openssl-0.9.8l</code> directory
* Run these commands:
** <code>perl Configure VC-WIN32</code>
** <code>ms\do_masm</code>
* Patch the <code>ntdll.mak</code> file generated by the previous steps (this fixes the DLL manifest settings so that they are compatible with the Second Life client build configuration)
** Copy the patch file <code>020-openssl-disable-manifest.patch</code> from the <code>C:\llqtwebkit-4.6\patches</code> to <code>C:\openssl-0.9.8l</code>
** Run this command:
*** <code>patch -p1 < 020-openssl-disable-manifest.patch</code>
* Continue to build
** <code>nmake -f ms\ntdll.mak</code>
* After a few minutes, the libraries <code>libeay32.dll</code> and <code>ssleay32.dll</code> will be built in the <code>C:\openssl-0.9.8l\out32dll</code> directory - confirm they exist - they will be needed later.

== Build the open source version of Qt 4.6.0 using Microsoft Visual Studio ==
=== Acquire the Qt 4.6.0 source with our patches ===
* Our clone of Qt is available here: http://gitorious.org/+lindenqt/qt/lindenqt
* Download the source by clicking on the "lindenqt" branch under "Branches:" and then using the "Download lindenqt as tar.gz" link on the right hand side of the page
** It's a large download - over 100MB - so it may take some time
** Alternately, if you prefer you can clone the repository with git using the "clone" link on the page -- details of this are left as an exercise to the reader
* Extract the contents of the tarball into <code>C:\qt-lindenqt</code>
* This may take some as the archive contains a lot of files
** Note: Different tools have different concepts of "contents" - you should end up with the directories and files in <code>C:\qt-lindenqt</code> and not <code>C:\qt-lindenqt\qt-lindenqt</code>
** Note: using Cygwin's <code>tar</code> command might not work. It may result in an '''Access is Denied''' error when running configure below. If so, try using WinZip, WinRAR or some other tool instead.

=== Configure Qt ===
* If it's not open already, open the "Visual Studio 2005 Command Prompt" (Start Menu->Microsoft Visual Studio 2005->Visual Studio Tools->Visual Studio 2005 Command Prompt)
* Change to the <code>C:\qt-lindenqt</code> directory
* Run this command:
<code>configure -debug-and-release -no-qt3support -no-phonon -no-phonon-backend -prefix C:\qt-lindenqt -qt-libjpeg -qt-libpng -openssl-linked -I C:\openssl-0.9.8l\include -L C:\openssl-0.9.8l\out32dll</code>
* When you are asked if you want to use the Commercial or Open Source version type <code>o</code> to select Open Source and press the Enter key
* When the license agreement appears, if you agree type <code>y</code> the Enter key
* This operation takes around 10-15 minutes on a typical development system

=== Build Qt ===
* Change to the <code>C:\qt-lindenqt</code> directory
* Run this command:
<code>nmake sub-src</code>
* This operation takes around 1-2 hours on a typical development system
* After building Qt, the release and debug libraries and dlls will be in <code>C:\qt-lindenqt\lib</code>

=== Configure a Qt runtime environment ===
* Copy the OpenSSL dynamic libraries (<code>C:\openssl-0.9.8l\out32dll\libeay32.dll</code> and <code>C:\openssl-0.9.8l\out32dll\ssleay32.dll</code>) to the Qt binary directory (<code>C:\qt-lindenqt\bin</code>)
* Create the file <code>C:\qt-lindenqt\bin\qt-vars.bat</code> and put the following in it:
@echo off
echo Setting up a Qt environment...
set QTDIR=C:\qt-lindenqt
set PATH=C:\qt-lindenqt\bin;%PATH%
set QMAKESPEC=win32-msvc2005
call "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"
* Make a shortcut to <code>qt-vars.bat</code> on your desktop
* Right-click on the shortcut and set the following properties:
Target: %COMSPEC% /k "C:\qt-lindenqt\bin\qt-vars.bat"
Start in: C:\qt-lindenqt
* Rename the shortcut to "Qt Linden Command Prompt".
* Test it by opening the prompt and typing
qmake --version
* Confirm that the Qt version displayed is 4.6.0

== Build LLQtWebKit ==
* Launch the Qt command prompt and enter the following in the command prompt:
cd C:\llqtwebkit
qmake CONFIG-=debug
nmake
* This operation takes just a few seconds on a typical development system
* If you want to build the debug version of LLQtWebKit, use <code>qmake CONFIG+=debug</code> instead
* Now LLQtWebKit is built and can be used in the Second Life viewer.
* If you want to build the test applications, follow the next steps:

== Acquire test application dependencies ==
=== Glut ===
* Glut is a cross-platform library that manages OpenGL state and creation/destruction of OpenGL windows
* The author provides a library and header for Windows so you do not have to build them yourself
* Download the library and headers from http://www.xmission.com/~nate/glut/glut-3.7.6-bin.zip
* Extract the contents of the zip to a new folder called <code>C:\llqtwebkit\tests\GL</code>

=== GLUI ===
* Glut is a cross-platform library that renders UI components in the uBrowser test application
* The author does not provide libraries for Windows so you have to build them yourself.
* Download the source code from http://sourceforge.net/projects/glui/files/Source/2.36/glui-2.36.zip/download
* Extract to <code>C:\glui-2.36</code>
* Copy <code>glut.h</code> from <code>C:\llqtwebkit\tests\GL</code> to <code>C:\glui-2.36\src\include\GL</code> as it is required to build GLUI
* Open <code>C:\glui-2.36\src\msvc\glui.sln</code> and let Visual Studio convert the project
* Select "Release" configuration of "_glui library" project and build it as normal
* Copy the GLUI header (<code>C:\glui-2.36\src\include\GL\glui.h</code>) to <code>C:\llqtwebkit\tests\GL</code>
* Copy the GLUI library you just built (<code>C:\glui-2.36\src\msvc\lib\glui32.lib</code>) to <code>C:\llqtwebkit\tests\GL</code>

== Build test applications ==
=== testGL ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\testgl
qmake CONFIG-=debug
nmake
..\GL\testgl.exe
* If you want to build the debug version, use <code>qmake CONFIG+=debug</code> instead and run <code>nmake clean</code> first

=== uBrowser ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\ubrowser
qmake CONFIG-=debug
nmake
..\GL\ubrowser.exe
* Important: <code>glui.h</code> contains a pragma that forces the build to always link against the release version - <code>glut32.lib</code> - instead of the debug version. This means building a debug version of uBrowser is currently broken.

=== QtTestApp ===
* Open the Qt command prompt using the shortcut you made and enter the following:
cd C:\llqtwebkit\tests\qttestapp
qmake CONFIG-=debug
nmake
..\GL\qttestapp.exe
* If you want to build the debug version, use <code>qmake CONFIG+=debug</code> instead and run <code>nmake clean</code> first

=== Win32GL ===
* Edit the path variables at the top of the <code>C:\llqtwebkit\tests\win32gl\copy_files.bat</code> directory to reflect the location of your OpenSSL, Qt and LLQtWebKit files.
* Run the <code>C:\llqtwebkit\tests\win32gl\copy_files.bat</code>
* Open the <code>C:\llqtwebkit\tests\win32gl\win32gl.sln</code> MSVC solution file
* Select <code>Release</code> configuration
* Build and run as normal

== Win32 Helper batch files ==
* There are some helper batch files for Windows developers that may prove useful.
* You will very likely need to configure settings at the top of each one to match the location of the files and directories on your system.
* They do not do much error checking so make sure you understand the ramifications of any changes you make.
* A useful pattern is to edit them so they only do what you need at that moment - build release LLQtWebKit and testGL for example - then revert them when you're finished.

=== Build LLQtWebKit and test apps ===
* Now you have built LLQtWebKit by hand, I'll point out this batch file which does it for you.
* <code>C:\llqtwebkit\make_all.bat</code> is a very simple batch file that will clean and build release and debug versions of LLQtWebKit and then clean and build release version of the test apps (except Win32GL).
* You will need to modify the GL_COMPONENT_DIR variable near the top that sets the location of the GLUT and GLUI build files.
* You almost certainly will want to run this batch file from a Qt command prompt as described above since various Qt directories need to be in the path.

=== Generate a directory tree compatible with the Second Life client build system ===
* <code>C:\llqtwebkit\copy_llqtwebkit.bat</code> is a batch file that:
** Generates a directory tree containing LLQtWebKit header and libraries along with the necessary Qt run time files that are required by the Second Life client.
** Builds a <code>tar.bz2 </code> archive and associated MD5 sum that can be used in the LLQtWebKit section of the Second Life client <code>install.xml</code> configuration file.

== Notes ==
* To enable a run time console for the test applications add a <code>CONFIG+=console</code> line to the <code>qmake </code> line.
* Make sure all libraries and applications are built as Multi-threaded Dll or Multi-threaded debug dll. In Visual Studio this is in Properties->configuration->c/c++->code generation->runtime library
* Make sure you do not mix release and debug versions of libraries and applications

Open Grid Public Beta/Teleport How To

2008-07-31T17:43:17Z

Leyla Linden:

== Download and Install Open Grid Viewer ==

# Download the viewer from (url tbd).
# The viewer is named "Open Grid" so you can install it without conflict with your existing Second Life viewer.
# Launch the viewer.

[[Image:Ogpb_teleport_howto_1.jpg]]

== Log In ==

# Note the new field, "Region URL" in the lower right hand pane of the splash/login screen.
# Enter "[http://sim1.vaak.lindenlab.com:13000 http://sim1.vaak.lindenlab.com:13000]", without quotes and without a trailing slash (see [https://jira.secondlife.com/browse/VWR-8382 VWR-8382] )
# Enter your user name and password, and press connect.

[[Image:Ogpb_teleport_howto_2.jpg]]

* When you login, you will be 'ruthed'.
* The system may also ask if you want your avatar to be male or female.

[[Image:Ogpb_teleport_howto_3.jpg]]

* Note that you will not have access to your inventory.

[[Image:Ogpb_teleport_howto_4.jpg]]

== Teleporting to an Open Sim Region ==

* From the "World" menu, select "Teleport Region".
** The teleport floater will only display if you originally logged in with a Region URL.

[[Image:Ogpb_teleport_howto_5.jpg]]

# Enter the URL of your patched OpenSim region.
# Press teleport.

[[Image:Ogpb_teleport_howto_6.jpg]]

* You will rez, once again, 'ruthed' on your OpenSim region.

[[Image:Ogpb_teleport_howto_7.jpg]]

* You can check "Help" > "About" from the menu to confirm that you are on your OpenSim region.

[[Image:Ogpb_teleport_howto_8.jpg]]

Congratulations! Gridnaut. You've Teleported Across The Grid!

Send a screenshot of your avatar (with nametag) and the about screen to the gridnauts list for your special Gridnaut bear.

== Troubleshooting ==

* If you see the not in gridnauts message when logging into the Open Grid viewer, please check your account on the beta grid with a release viewer to confirm you are in the gridnauts group.

[[Image:Ogpb_teleport_howto_9.jpg]]

* You may see a "you do not have access to that teleport destination" message, even if you successfully teleported.

[[Image:Ogpb_teleport_howto_10.jpg]]

* If you get an invalid region error when you attempt to teleport, check your OpenSim's bin/Regions/default.xml
** The attributes sim_location_x, and sim_location_y should not conflict with coordinates on the Second Life grid.
** Check the page [[Open_Grid_Public_Beta/Map_Locations]] and claim a non-conflicting set of coordinates.

[[Image:Ogpb_teleport_howto_11.jpg]]

[[Category:Open_Grid_Public_Beta]]

SLGOGP Teleport Strawman

2008-07-29T23:44:05Z

Leyla Linden: /* Response */

This strawman represents a possible open teleport protocol. The sequencing is described first, which also introduces the major players: Client, Agent Domain, Simulator/Region Domain A, Simulator/Region Domain B. For perspective, the current Second Life Grid teleport flow is also included. Following that are the draft specifications for the two main pieces, called rezAvatar and derezAvatar on the agent domain. The simulator side portions of this protocol have been tentatively dubbed "teleport_avatar" and "give_up_av_to_pipe".

= Teleport Flow =

Here is the basic flow for current SL teleports:
[[Image:Old teleport.png]]

Fine tuning the proposed protocol and cap names after discussion with AWG groupies resulted in a unified approach for Login, Teleport, and Logout, diagrammed below:

== Login ==
[[Image:Strawman-login-flowchart.png]]
[[Image:Open grid login.png]]

== Teleport ==
[[Image:Open Grid Teleport.png | 760px]]

== Logout ==
[[Image:Open Grid Logout.png]]

= Authentication =

*In order to get the agent host seed capability, credentials must first be posted to http://login.aditi.lindenlab.com/cgi-bin/auth.cgi

== Request: viewer -> auth.cgi ==

=== Required Parameters ===
{
'firstname': <string>,
'lastname': <string>,
'password': <string>
}

or

{
'firstname': <string>,
'lastname': <string>,
'md5-password': <string>
}

=== Optional Parameters ===
{
'agree_to_tos' : <bool>,
'read_critical': <bool>
}

== Response ==

=== Successful ===

status: 302

{
'authenticated': true
'location' : <agent host seed capability url>
}

* Note: the 302 status code will be changed to 200 status in the future

=== Unsuccessful ===

status: 4xx - login was unsuccessful
status: 5xx - server error

{
'authenticated' : false
'reason' : <one word identifier>
'message' : <error description>
}

*Non-transport/server errors will be changed to 200 status in the future

Terms of Service

{
'authenticated' : false
'reason' : 'tos'
'message' : <terms of service text>
}

*Once user agrees to terms of service call authenticate again with { 'agreed_to_tos' : true }

Critical Message

{
'authenticated' : false
'reason' : 'critical'
'message' : <critical message text>
}

*Once user has read the message call authenticate again with { 'read_critical' : true }

Miscellaneous Reason

* data - bad input or server side data fetch failed
* key - bad password
* god, restricted, ban, suspend, disabled - denied based on account details

= Agent Information =
{| border="1"
|-
| colspan="2" |
Agent Information
|-
|
Name
|
agent/info
|-
|
URL
|
capability from agent domain
|-
|
Verb
|
GET
|-
|
Response
|
{ agent_id: <uuid>, circuit_code: <int>, session_id: <uuid>, secure_session_id: <uuid>, presence: { status : online|offline, region_url: <url> }
|-
|

|
a map of agent information for this session
|}

= rez_avatar/place =
* Once the viewer acquires the cap for place_avatar, it requests it from the agent domain
* The viewer can also invoke place_avatar for teleport
== Request: viewer -> agentd ==
{
'region_url': <r_url>
'position': [x, y, z]
}
== Response ==
{
'seed_capability': uri string
'look_at' : [f32, f32, f32]
'sim_ip': ip string
'sim_port': int
'region_x': int
'region_y': int
'region_id' : uuid
'sim_access' : <PG/Mature>
'connect': bool
'position': [f32, f32, f32]
// The above are the same as response to rez_avatar
// The following are only returned on login, not over teleport
'session_id':<uuid>
'secure_session_id':<uuid>
'circuit_code':<int>
}

= rez_avatar/request =
== Request: agentd -> simulator ==
{
'agent_id' : <uuid>,
'first_name': <string>,
'last_name': <string>,
'age_verified' : <boolean>,
'agent_access' : <boolean>,
'allow_redirect: <boolean>,
'god_level': <int>,
'identified': <bool>,
'transacted': <bool>,
'limited_to_estate': <int>
'sim_access' : <PG/Mature>,
'granters': []
}

== Example: (hard coded) ==
{
'agent_id' : <uuid>,
'first_name': <string>,
'last_name': <string>,
'age_verified' : false,
'agent_access' : false,
'allow_redirect: 1,
'god_level': 0,
'identified': false,
'transacted': false,
'limited_to_estate': 1
'sim_access' : 'PG'
}

== Response to request_rez_avatar ==
{
'connect':True
'rez_avatar/rez':<cap>
'sim_ip': ip string
'sim_port': int
'region_x': int
'region_y': int
'region_id' : uuid
'sim_access' : <PG/Mature>
'seed_capability': uri string
Optional params for Second Life regions only:
'src_can_see_mainland':<bool>,
'src_estate_id':<int>
}

Failed request.
{
'connect':False
'redirect':False
'resethome':False
'message': string
}

Failed request. Need to reset home location.
{
'connect':False
'redirect':False
'resethome':True
'message': string
}

Failed request. Need to redirect to new location
{
'connect':False
'redirect':True
'resethome':False
'message': "You have been redirected to a telehub."
}

= rez_avatar/rez =
== Request: agentd -> simulator OR simulator a -> simulator b via derez_avatar ==
* For login, the agent domain then invokes rez_avatar on the simulator at the given region_url
* For teleport, the agent domain invokes derez_avatar on simulator a, which invokes rez_avatar on simulator b
{
'circuit_code': <int>,
'god_overide': <bool>,
'position': [x, y, z],
'secure_session_id': <uuid>,
'session_id': <uuid>,
'inventory_host': <uri string>, // not really here!
'voice_password': <string> // what to do?

// The following are only sent from simulator a -> simulator b via derez_avatar
// Note: No assets are actually being sent through when going from SL -> non-SL regions
'attachment_data': [ {'attachment_point':<int>, 'item_id':<uuid>, 'asset_id':<uuid> | 'asset_data':<binary>}...]
'baked_texture_data': [ {'texture_id':<uuid>, 'asset_host_name':<host?????>}...]
'texture_data': [ <uuid>...]
'animations':[{'state':<uuid>, 'source':<uuid>, 'sequence':<int>}...]
}

== Response: simulator -> agentd ==
* The simulator then returns the actual region (in case it might be different from requested) and the seed cap.
{
'look_at' : [f32, f32, f32]
'position': [f32, f32, f32]
// Extra stuff
'connect': <bool>
}

= rez_avatar/derez =
== Request: agentd -> simulator a ==
{
'rez_avatar/rez': <url>
'position': [x, y, z]
}
Response: simulator a -> agentd

== Response: simulator -> agentd ==
{
'look_at' : [f32, f32, f32]
'position': [f32, f32, f32]
// Extra stuff
'connect': <bool>
}

= Maintenance =

OGP Maintenance refers to an extension of the existing OGP Login protocol to support per-user maintenance tasks when an agent "logs in." Per-user, login-time maintenance is considered "better" in some cases than universal maintenance because:

# it reduces the requirement for system-wide downtime
# assuming that all agents do not "log in" simultaneously, it distributes the load of maintenance across time
# and, it consumes system resources only for those agents who actually "log in."

It is not, however, without disadvantages:

# performing per-user maintenance can lead to more complex systems
# agents who do not "log in" frequently will experience delays as pending maintenance is performed.

== Dramatis Personae ==

* the user : the human or automated service on whose behalf interaction with the grid is initiated
* an account : an administrative convenience maintained by the agent domain on behalf of the user "containing" one or more agents
* the agent : a specific actor on the grid, identified uniquely by a name, a UUID and a credential
* the client : the software component participating in the protocol with the agent domain and optionally (hopefully) a region
* the agent domain : a collection of systems that respond to OGP and report and manipulate agent related information
* the credential : a syndrome of a shared secret presented by the client to the agent domain on behalf of the user
* a maintenance token : an opaque data structure representing maintenance being done by the agent domain on the user's behalf

== Requirements ==

* Maintenance must occur subsequent to authentication
* The client must be alerted that maintenance is occurring
* The agent domain must not require a client to re-authenticate themselves in order to check on the status of ongoing maintenance, once the client has been informed that maintenance is occurring (subject to reasonable limitation on the validity period of the credential)
* The agent domain must use the initial authentication (that started the maintenance process) to continue the login process (subject to reasonable limitation on the validity period of the credential)
* (reasonable limitation on the validity period of a credential)
** In situations where a credential has a validity period (X.509, OpenID, etc.) the agent domain must not depend on an authenticator after it's validity period is expired.
** An agent domain may choose a "reasonable" validity period for credentials that do not have an explicit validity period (shared secret, SRP, etc.)
* The agent domain should give the client an estimate on how long maintenance should last
* If a user "logs in" using two distinct clients with the same agent, the agent domain should provide the same maintenance token to both clients
* The agent domain must expose an interface allowing the client to use the maintenance token to retrieve status information regarding ongoing maintenance

== A Few Comments ==

* If the agent domain has a good estimate for how long maintenance will take, it may choose to delay responding to maintenance caps for some period of time.
** This has the benefit of discouraging clients from repeatedly querying for status updates.
* If the agent domain does not have a good estimate for how long maintenance will take, it may choose to insert a smaller delay in responding to maintenance caps.
** This will allow the client to retrieve progressively more accurate estimates of maintenance lengths.

== How it maps to the existing implementation ==

* the "maintenance token" is a "maintenance cap"
* when auth.py determines that a transform must be applied, it:
** checks to see if maintenance is under way. If it is not, it:
*** queries ??? for a new maintenance cap
*** updates the user_transformation table to include the current maintenance cap that is executing
*** tells ??? to start performing transforms
** then returns the current maintenance cap

== Open Questions ==

* it's possible for an agent to have several transformations to be applied (denoted as several rows in the user_transformation table), so:
** do we use the same maintenance cap for each transformation, or do we create a new cap for each transform?

== Maintenance / Transform ideas ==

Current Maintenance Flow:
* next_url -> transform.cgi
* viewer POST credentials again to transform.cgi (not okay for protocol)

OGP Maintenance
* next_url is a cap
* Need expiry/lifetime of cap -> connect to user.transform_until
* If transform_until: give back same cap for next_url

credential is { password | openid url }

Viewer Auth.py
(name,credential) ==>
* do authentication
* is a transform currently being performed?
* return transform cap
* is there a transform?
* get cap for transform
(name,transform type) ==>
<== (cap)OGP Maintenance

[[Category:Grid_Interoperability]]
[[Category: Pyogp]]

SLGOGP Teleport Strawman

2008-07-28T23:27:39Z

Leyla Linden: /* Unsuccessful */

SLGOGP Teleport Strawman

2008-07-28T22:57:23Z

Leyla Linden: /* Successful */

SLGOGP Teleport Strawman

2008-07-28T22:56:50Z

Leyla Linden: /* Unsuccessful */

SLGOGP Teleport Strawman

2008-07-28T22:54:10Z

Leyla Linden: /* Authentication */

SLGOGP Teleport Strawman

2008-07-28T22:49:51Z

Leyla Linden:

Second Life Login API Strawman

2008-06-11T22:54:18Z

Leyla Linden: /* Response */

{{multi-lang}}
 This page is now deprecated. It is retained in the wiki for transparency and for the discussion. The login protocol is now a part of the [[SLGOGP_Draft_1 | SL Grid Open Grid Protocol]] doc and should be referenced there
= Second Life Login API Strawman =
This is a work in progress. Also see a similar Strawman by AWG: [[AWG_flows_login]]
Innitial meeting with AWG to request feedback on protocol: [[AWGroupies-2008-02-19|Feedback Chat-log, 19 Feb 2008]]

== Introduction ==
This page attempts to merge [[Authentication_Flow]] with [[Current_login_protocols]] and adds additional protocol changes to fit with [[Agent_Domain#How_login_works]]. The goal is to expose a protocol allowing login to a separate region domain while making incremental, small changes to the current protocol.

== Summary ==
# *Viewer sends credentials to the Login Service [[#Login_Web_Service]]
# Login Service authenticates and sets up and queries for presence:
#* Queries the agent data from the Agent Store.
#* Finds an agent host, POST's agent presence checking for already online
#* grants seed capability, which lives on an agent host
# *Viewer requests capabilities needed for login via received seed capability. [[#Seed_Capability]]
# *(future) Viewer Polls Agent Host for messages via long-poll [[#poll_for_messages_Capability]]
# *(future) Viewer can send instant messages before being in world. [[#instant_message_Capability]]
# *Viewer invokes legacy_login capability [[#legacy_login_Capability]]
#* Initialization data returned by login
#* Sets up agent presence
#* Forwards location request to region domain, finding a region to rez the avatar
#* Establishes session with region host, which gives back a (region domain) seed capability to the client
# *Viewer invokes region seed capability

== Definitions ==
=== Seed Capability ===
The current Login Seed Capability is a [[Capabilities|Capability]] associated with the simulator you are logging into. It should not be confused with the [[#Agent_Seed_Capability]] proposed for the new protocols.

=== Agent Seed Capability ===
This is a newly introduced capability associated with the agent host as part of the agent domain.
This is different from the previously mentioned seed-capability, which associates with the sim host as part of the region domain.

== Conventions ==
On this page the following conventions are used:

:"--" followed by text, indicates a comment until the end of line, ala the C++ "//" style comments.
:< represents a value which can be substituted by an appropriate string described inside >
:< represents a list of choices | separated by a vertical bar >
:"..." ellipses indicates an unknown list of similar values follow
:"<int>" represents an [[integer]] value
:"<uuid>" represents a [[UUID]] value, e.g., 'c5853f4c-855f-4013-ce92-aabc59f1b9d8'
:The remaining syntax follows (very roughly) that of Python data structures:
::"in quotes is a literal string"
::{ <represents a map or dictionary of one or more key>:<value pairs> } -- separated by commas
::[ represents an array, of elements, separated by commas ]
::'represents a string that must be quoted, but how will be implementation specific' for example in LSL "" denotes a string and " will be used in place of the single quote (').
::+ means to concatenate the two parts, though how will be implementation specific, for example + can be used to concatenate strings.

== Login Web Service ==
Client --> public Login Server: "Here is my credential, and optional agent identity desired"
Second Life Login Server: https://login.agni.secondlife.com/app/login/

The login will be done using standard http/1.1 POST and the default format for all parameters in POST and RESPONSE will likely be "content-type" = "application/xml" and the actual xml format will be the [[LLSD#Example_XML_Output|text serialization of Linden Lab's XML-LLSD format]]. Future formats will be negotiated using [http://www.w3.org/Protocols/rfc2616/rfc2616-sec12.html#sec12| standard http/1.1 Content Negotiation].
=== Required Parameters ===
{ 'credential': { 'type': 'agent',
'first_name': <first>,
'last_name': <last>,
'password': '$1$' + <passwd_md5> } }
OR (future)
{ 'credential': { 'type': 'account',
'account_name': <IBM>,
'password': '$1$' + <passwd_md5> } }
OR (future)
{ 'credential': { 'type': 'openid',
'url': <URL> } }

OR (future)
{ 'credential': { 'type': 'agent',
'first_name': <first>,
'last_name': <last>}}
which will need to a challenge from the auth system.

== Optional Parameters ==
Optionally, specify which account you want this credential to log you into
{ 'credential': { 'type': 'agent',
'first_name': <first>,
'last_name': <last>,
'password': '$1$' + <passwd_md5> },
'first_name': <first>,
'last_name': <last> }
=== Response ===
Response Codes : Response
200 : Successful authentication.
{ 'agent seed-capability' : <url> -- agent domain seed capability] }
4xx : If this credential has more than one account linked to it, and no specific account was specified in the optional parameters, the response will list a set of accounts to choose from.
{ 'reason': 'select account', -- reason why authentication failed
'accounts' : [ { 'first_name' : <first>, 'last_name' : <last> },
{ 'first_name' : <first>, 'last_name' : <last> },
... ] }
4xx : Unsuccessful authentication due to need for more information.
{ 'reason': <'tos'|'critical'|'more info'>, -- reason why authentication failed
'redirect' : <url> } -- URL to visit to get more information on how to proceed
Other reasons:
* no agent - 404
* bad identity and authentication information - 403
* agent not enabled (banned) - 403
5xx : Server unavailable.
{ 'reason': 'generic' }

== Seed Capability ==
Client -> Agent Host (via seed cap): "I want cap X"
* This service supports named capabilities for the agent domain requested by the client
=== Required Parameters ===
Map of named capabilities to Options
{ 'caps': {<capability name> : { 'enabled' : <'true' | 'false'> },
<capability name> : { 'enabled' : <'true' | 'false'> },
... }
}
<- Ok, here's the cap to do X
-or-
<- Bzzzp, you don't get to do X

=== Response ===
Map of capability name to capability URL:
{ 'caps': {<capability name> : <url>, <capability name> : <url>, ... }}

=== Example: Basic Login Capabilities ===
POST data:
{ 'establish_presence' : { 'enabled' : 'true' },
'inventory' : { 'enabled' : 'true' },
'non_existent_cap' : { 'enabled' : 'false' },
'be_in_world' : { 'enabled' : 'true' } }
Response value:
{ 'establish_presence' : <cap GO>, 'inventory' : <cap I>, 'be_in_world' : <cap CTR> }

== RezAvatar Capability ==
This is the hypothetical proposed protocol for the future with many region domains.

RezAvatar agent host service
{'region_url': <r_url>, 'position': [x, y, z]}
->
{'session_id': <s_id>, 'secure_session_id': <ssid>, 'circuit_code': <cc>,
'seed_cap': <s_cap>, 'ip_address': <ip_address>, 'udp_port': <udp_port>, 'look_at': [lx, ly, lz]}

The RezAvatar agent host service invokes the RezAvatar region host service on behalf of the client.

RezAvatar region host service
{'avatar_id': <a_id>, ..., 'position': [x, y, z]}
->
{'seed_cap': <s_cap>, 'ip_address': <ip_address>, 'udp_port': <upd port>, 'circuit_code': <cc>, 'session_id': <s_id>, 'secure_session_id': <ssid>, 'look_at': [lx, ly, lz]}
or
403 Forbidden

== legacy_login Capability ==
This is for connecting to an existing sim.

* Viewer -> Agent Host (via cap LL): "I'd like to log in using the legacy login protocols"

=== Required Parameters ===
{ 'start': <"first" | "last" | <uri> >,
"channel": <channel>,
"version": <client version>,
"platform": <"Lin" | "Mac" | "Win">
"mac": <MAC Address>,
"options": <array of strings>,
"id0": <uuid>,
"agree_to_tos": <"true" | "false" | "">,
"read_critical": <"true" | "false" | "">,
"viewer_digest": <uuid>,
"options" : [array of strings] }
'''start''' check for trust against region domain, attempt to log in to this region. If it is full or not available, or the agent is not allowed, invoke region domain service to select another. "First" means home location. If home is filled then the grid will try last. If last is filled and home is set, the grid will try home. If neither works, region domain will find a region to put you on.

'''channel''' the name of the client. Used to differentiate official viewers from third party clients.

'''options''' See [[Second_Life_Login_API_Strawman#Optional Parameters|Optional Parameters]]

'''id0''' hardware hash (based on the serial number of the first hard drive in Windows) used for uniquely identifying computers.

'''viewer_digest''' MD5 hash of the viewer executable, only relevant when the channel is set to an official Second Life viewer.

=== Optional Parameters ===
The "options" key points to an array of optional options. Zero or more of the following character strings may appear in any order in the array:
{ 'options' : <"inventory-root" | "inventory-skeleton" | "inventory-lib-root" |
"inventory-lib-owner" | "inventory-skel-lib" | "gestures" | "event_categories" |
"event_notifications" | "classified_categories" | "buddy_list" | "ui-config" |
"login-flags" | "global-textures">* }
See [[Second_Life_Login_API_Strawman#Optional Response|Optional Response]] for descriptions of information returned from these options

=== Required Response ===

The valid (non-error) value returned by the login call is in standard xmlrpc name, value format. The most important of these is the [[Current_login_protocols#Login_Seed-Capability|"Login Seed-Capability"]] discussed below (not to be confused with the new "seed capability" for the new login procedure):
{ "last_name" : lastname ,
"sim_ip" : 64.129.40.58 ,
"start_location" : last ,
"seconds_since_epoch" : 1195447316 ,
"message" : -=- http://blog.secondlife.com -=- Visit the Official Linden Blog for the latest world status updates! ,
"first_name" : first_name ,
"circuit_code" : 245160577 ,
"sim_port" : 13005 ,
"secure_session_id" : fdb501ca-22f1-4470-b515-2650f54b8117 ,
"look_at" : [r-0.85717299999999996274,r0.51502899999999995906,r0] ,
"agent_id" : d5f403c7-7981-425d-a0b5-c65a3d0a4693 ,
"inventory_host" : inv12-mysql ,
"region_y" : 244992 ,
"region_x" : 247808 ,
"seed_capability" : https://sim2054.agni.lindenlab.com:12043/cap/d373fdc9-d275-e484-3ad2-4a9b231f4e34 ,
"agent_access" : M ,
"session_id" : 65a7213a-723a-4fcf-baca-7b247c4b43c5 ,
"login" : true }

=== Optional Response ===
:Note: all return values are in "name: value" format as used in [http://docs.python.org/lib/typesmapping.html Python 2.5 dictionaries] unless otherwise noted.

'''inventory-root'''
:UUID of the agent’s root inventory folder.
{ 'inventory-root': [{'folder_id': <uuid>}] }

'''inventory-skeleton'''
:Initial list of folders in agent’s inventory. Returned as an array of five-entry dictionaries. Each dictionary element describes a folder with its name, version, type, its UUID, and the UUID of the containing folder.
{'inventory-skeleton': [{'parent_id': <uuid>, 'version': <int>, 'name': <name>, 'type_default': <int>, 'folder_id': <uuid>}, .... ]}

'''inventory-lib-root'''
:folder_id of library root inventory folder.
{ 'inventory-lib-root': [{'folder_id': <uuid>}] }

'''inventory-lib-owner'''
:agent_id of owner for inventory lib.
{ 'inventory-lib-owner': [{'agent_id': <uuid>}] }

'''inventory-skel-lib'''
:Initial list of folders in agent’s inventory. Returned as an array of five element dictionaires. Each dictionary describes a folder with its name, its UUID, the UUID of the containing folder, its type, its version.
{'inventory-skeleton': [{'parent_id': <uuid>, 'version': <int>, 'name': <name>, 'type_default': <int>, 'folder_id': <uuid>},... ]}

'''gestures'''
:List of active gestures. An array of two element dictionaries with the inventory item uuid and the asset uuid.
{ 'gestures': [{'item_id': <uuid>, 'asset_id': <uuid>},...] }

'''event_categories'''
:List of different event categories, mapping category id (an integer) to a category name. Returned as an array of two element dictionaries. Each dictionary describes a category’s id and it’s name.
{ 'event_categories': [{'category_id': <int>, 'category_name': <name>},...] }

'''event_notifications'''
:List of events for which the agent has pending notifications. An array of eight-element dictionaries containing: event_id, event_name, event_desc, event_date, grid_x, grid_y, x_region, y_region.
{'events': [{"event_id":<uuid>, "event_name"<name>,"event_desc":<string>, "event_date":<date>, "grid_x":<float>, "grid_y":<float>, "x_region":<float>, "y_region":<float>}, ...]}

'''classified_categories"'''
:List of classifieds categories, mapping category id (an integer) to a category. Returned as an array of two element dictionaries with a category’s id and it’s name.
{ 'event_categories': [{'category_id': <int>, 'category_name': <name>},...] }

'''buddy-list'''
:List of friends with granted and given rights masks. Returned as an array of three-element dictionaries with riend’s agent id, granted rights mask, given rights mask.
{ 'buddy-list':[{'buddy_id': <uuid>', 'buddy_rights_given': <int>, 'buddy_rights_has': <int>}, ....] }

'''ui-config'''
:list of UI enabled/disabled states, currently: allow_first_life ('Y' or 'N') for teens.
{ 'ui-config': {'allow_first_life': if allow first life} }

'''login-flags'''
:Several flags about the state of the agent.
{ 'login-flags': {'stipend_since_login': <'Y'|'N'>, 'ever_logged_in': <'Y'|'N'>, 'gendered': <'Y'|'N'>, 'daylight_savings': <'Y'|'N'>} }

'''global-textures'''
:The asset ids of several global textures.
{ 'global-textures': {'sun_texture_id': <uuid>, 'moon_texture_id': <uuid>, 'cloud_texture_id': <uuid>} }

[[Category: AW Groupies]]

Talk:SLGOGP Draft 1

2008-03-27T21:56:00Z

Leyla Linden: moved transforms discussion into the legacy login discussion section

SLGOGP Draft 1/Discuss 3-2 Legacy Login

2008-03-27T21:54:30Z

Leyla Linden: New page: == 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....

== 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

<code>{ login: true }</code>

but will instead include

<code>{ login: indeterminate, next_url: ''transform_url'', next_method: transform, message: ''a status update'' }</code>

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

<code>{ login: true, next_url: ''login_url'', next_method: login_to_simulator }</code>

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.

[[User:Leyla Linden|Leyla Linden]] 17:17, 26 March 2008 (PDT)

Talk:SLGOGP Draft 1

2008-03-27T00:17:29Z

Leyla Linden:

== wiki-typo ==

<nowiki>::All contributions to this document must be contributed under the Second Life Project Contribution Agreement. See http://wiki.secondlife.com/wiki/Project:Contribution_Agreementfor details </nowiki> should be <nowiki>::All contributions to this document must be contributed under the [[Project:Contribution Agreement|Second Life Project Contribution Agreement]].</nowiki>

[[User:SignpostMarv Martin|SignpostMarv Martin]] 11:05, 11 March 2008 (PDT)

How does this take into account Open Avatar efforts?
--[[User:Destiny Niles|Destiny Niles]] 12:09, 11 March 2008 (PDT)

Wiki content licensing is specified in the footer of every page, including this one. It can't be changed arbitrarily either, unless new content avoids reusing old content which is under [http://creativecommons.org/licenses/by-sa/2.5/ CCAS] license, which would be pretty silly. This is a wiki after all. Its very purpose is unhindered cooperation and building upon the work of others. [[User:Morgaine Dinova|Morgaine Dinova]] 14:52, 11 March 2008 (PDT)

== 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

<code>{ login: true }</code>

but will instead include

<code>{ login: indeterminate, next_url: ''transform_url'', next_method: transform, message: ''a status update'' }</code>

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

<code>{ login: true, next_url: ''login_url'', next_method: login_to_simulator }</code>

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.

[[User:Leyla Linden|Leyla Linden]] 17:17, 26 March 2008 (PDT)

Talk:SLGOGP Draft 1

2008-03-27T00:15:54Z

Leyla Linden: New section: Legacy Login Transforms