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

[Sean Dague]

On Thu, Jan 10, 2008 at 09:24:10AM +0100, Dr Scofield wrote:
> Sean Dague wrote:
>> 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 completely agree...the question is can we get this to work given that we 
> already have a few of those secondlife://Bla%20bla%20/127/104/88 URIs 
> around? it might work as long as you don't have island names that are valid 
> FQDN...

The host portion of the secondlife:// URL should be the grid entry
point, not the hostname of the sim itself.  Much like you don't know
which physical machines you are hitting when you go to
http://www.amazon.com.

The way you get to introducing hostname into secondlife:// is pretty
easy.

 1. Make the client support hostname optionally
 2. Make all the tools that create SLURLs generate the hostname
    explicitly as part of the tool
 3. Deprecate the concept of SLURLs without hostname RSN
 4. After a reasonable time, phase out the non-hostname SLURLS
    (i.e. 1.20.x client timeframe).

We've seen force client upgrades of incompatible bits in the past.
Doing so for extremely sensibly architecture reasons should be at least
as valid as doing so because Internet Explorer has bugs in URL handling.

We are now 4 months after the kickoff of the AWG in SF, and hitting the
first of the architectural issues that both directly affect the grid
today, and the architectural sanity of future grids.  Taking the
shortcuts here are already causing pain for OpenSim trying to
interoperate with software on the main grid.  

I also think these kinds of shortcuts jepordize the ability of
secondlife to be the seed for standards around virtual worlds.  Doing
this sensibly will take only a few extra weeks of time, but the pay off
will be much greater down the road in terms of extensibility and
likeness to existing standards that makes people want to build more bits
compatible with the protocol and the environment.

    -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/20080110/892fafed/attachment.pgp