[sldev] Re: [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues

[Sean Dague]

On Wed, Jan 09, 2008 at 11:56:08AM +0100, Dr Scofield wrote:
> the new web based authentication scheme uses a web page to capture the 
> fullname and the password of an avatar and returns a web_login_key that is 
> passed to the LL SL client via a secondlife:///app/login/... URI. the LL SL 
> client takes that secondlife:///app/login/... URI and extracts the 
> web_login_key (and first and last name and other stuff it seems) and goes 
> to the login service to log the avatar/agent in to the grid.
>
> while this works with the LL grid, it does not work with OpenSim grids, 
> because the LL SL client has no clue that it needs to go to a different, 
> non-LL grid login service: the latest release clients and the windlight 
> client do provide the -loginpage which would allow us to direct the client 
> to a login page of our own, where we could then generate the 
> secondlife:///app/login/.. URI --- however, that URI does not include any 
> reference whatsoever to the grid you want to connect to (well, it does to 
> some extent: there is a 'grid' parameter but that only knows about LL grids 
> and also does not include ports, resources, etc)
>
> teravus ousley has described this in much more detail (and probably better 
> than i have) in VWR-4021 (https://jira.secondlife.com/browse/VWR-4021). he 
> also tried several other things (have a look at VWR-4021, if you are 
> interested in the details) to no avail: we cannot get the latest windlight 
> and RC clients to connect to OpenSim grids/servers.
>
> luckily, we had a chance to discuss this with tess linden at yesterday's 
> AWGroupies meeting. the following two proposals came up:
>
>    (a) use the currently empty host part of the secondlife:///app/login
>    URI to specify the grid server: that is, to connect to my 4x4
>    OpenSim grid running here in the lab, i'd have the following URI:
>
>        
> secondlife://secondlife.zurich.ibm.com:9000/app/login?...&web_login_key=....
>
>    the LL SL client would simply do a s/^secondlife:/http:/
>    substitution and use the resulting URL to login the avatar in.
>
>    (b) recast the currently used grid parameter to always contain the
>    FQDN of the grid server along with port and resource; that is, for
>    my lab grid that would be:
>
>        
> secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=....
>
>    here the client would have to parse the URI, extract the grid
>    parameter, un-quote its value, then construct the login URL and
>    login the avatar in.
>
> clearly, approach (a) seems to be the cleanest approach and fits well with 
> the common URI scheme. however...
>
> ...during the discussion it transpired that the reason the host part of the 
> secondlife:/// URI is empty, is that the target of that SLURL is *not* the 
> grid server but the *client*! in particular, /app/login signals to the 
> client what it should do: login via a URL that it needs to construct from 
> the supplied URI.
>
> ...also, as fword utorid remarked, using the secondlife: URI to trigger a 
> grid login adds a new semantic to the secondlife: URI --- so far it has 
> been used as a kind of secondlife GPS location fix: 
> secondlife://IBM%206/127/104/88 addresses a unique location on the IBM 6 
> island, for example. now, secondlife:///app/login?... addresses the 
> secondlife client and tells it to do a login to a grid.

I (aka neas bade) will continue to express frustration on this design
point.  I know that secondlife:/// URI-like-things are currently used as
a hack to get a webbrowser to trigger an external application, however I
think that sticking with that design point causes confusion as well as
leads to the implicit hardcoding of the main grid into the client.

secondlife://osgrid.org:8002/app/login equaly conveys to the client what it
should do, that is connect to a network resource for login.  If we have
append the web_login_key= to this request, we can fully process that URI
back to the server as a well understood resource on the network,
returning to us any appropriate further information needed.

secondlife://IBM%206/127/104/88 brutally demonstrates how badly implicit
hostname is in this URI scheme.  That really should be
secondlife://secondlife.com/IBM%206/127/104/88, which would let you load
SLURLs for other grids in a sensible way (and you'd get appropriately
prompted for credentials in the equiv of HTTP AUTH domains).

I really think the further these approaches differ from the well
understood sematics of URIs on the www, the harder it will be to have
real interoperability between multiple grids.  My understanding of the
early tennents of the future grid work was to use the fundamental model
of the www unless there were massively compelling reasons why one
couldn't.  I don't see the massively compelling reason in not making
hostname explicit as part of secondlife:// URIs.  And I also think that
repeats of it taking over a month to get -loginpage to work with
alternate grids (it still doesn't work in released code) will continue
if the design of URIs used in the system continues to be host name
implicit.  Search is another good instance of this, but there are many
more that can be found by grepping for secondlife.com in the XUL files
for the client.

    -Sean

-- 
__________________________________________________________________

Sean Dague                                       Mid-Hudson Valley
sean at dague dot net                            Linux Users Group
http://dague.net                                 http://mhvlug.org

There is no silver bullet.  Plus, werewolves make better neighbors
than zombies, and they tend to keep the vampire population down.
__________________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20080109/e77721bb/attachment-0001.pgp