[AWG] further discussions of secondlife:/// (was Re: [sldev] [VWR] summary of VWR-4021 discussion from 2008-01-08 AWGroupies meeting & general hostname issues)

[dirk husemann]

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.
>
> the majority of the participants in the discussion did favor approach 
> (a), but given the way the secondlife:/// URI is currently used, the 
> most pragmatic approach for the time being seems to be (b). that will 
> work, but it doesn't really fit well into the "web way of doing 
> things" --- a better approach would be to have another URI scheme name 
> allocated for grid login URI, for example, secondlifegrid:
>
> finally, as was pointed out by neas bade, the login page is not the 
> only place that  we encounter the assumption that the client will only 
> be used with LL grids --- search, as neas, said is another example. 
> getting rid of all those silent assumptions (and returning the search 
> URI as part of the seed caps, for example) is really a necessary next 
> step if we want to have interoperability!
>
> so, in summary
>
>     (1) we have a pragmatic (kludgy?) solution proposal to providing
>     the grid to use via the login page; though, wouldn't it be better
>     to have a different URI scheme name for grid logins? for example,
>
>         secondlifegrid://grid.server.com:port/resource/login?...
>
>
>     (2) we need to get rid of all silent assumptions about the grid
>     being an LL grid.
>
during zero's office hours yesterday (at 
http://slurl.com/secondlife/Grasmere/178/113/27 not 
secondlife://Grasmere/178/113/27, btw!) we had a chance to discuss the 
semantics of the secondlife:/// URI scheme with zero:

    * the assumption that secondlife://Grasmere/178/113/27 addresses a
      location in the LL grid is actually *wrong* --- according to zero
      the correct URI for that is
      http://slurl.com/secondlife/Grasmere/178/113/27 !
    * the secondlife: URI scheme name is actually meant to only address
      the secondlife client and control it, but not to address location
      in the LL grid

based on that context the apparently "kludgy" solution to use

    secondlife:///app/login?...&grid=secondlife.zurich.ibm.com%3A9000&web_login_key=....

actually makes sense: it communicates to the secondlife client to do a 
login and to use as grid secondlife.zurich.ibm.com:9000. and that is 
fine, as the secondlife: URI scheme was never intended to address 
locations within a grid, let alone a grid --- contrary to common 
conceptions.

however, at the end of the discussion we had agreement that for grid 
interoperability we need to have a way of address locations within grids 
--- not just the LL grid but *any* grid:

    * secondlife;//Grasmere/178/113/27 tells the client to go to the
      178/113/27 on the Grasmere island on the presently connected grid,
      how would we tell the client to go to Grasmere on the UK's lake
      district grid?
    * http://slurl.com/secondlife/Grasmere/178/113/27 is a bit better,
      as it would allow to introduce other grid names --- nevertheless,
      there are a couple of issues with that:
          o the client (currently) provides no way to input that URL :-(
          o how do i get my grid registered with slurl.com? why should
            slurl.com become the gatekeeper?

as zero suggested (and fword utorid before him during the discussion at 
this week's AWGroupies meeting), we in all likelihood need a different 
URI scheme for that, one that allows us to specify grid and location. 
the question is, should information such as the login point be included 
in that new URI scheme or will we get that via an indirection (REST 
request to the grid name which would have to be a FQDN to retrieve the 
login URL?) --- i tend towards the later.

    cheers,
    dr scofield

-- 
dr dirk husemann, pervasive computing, ibm zurich research lab
--- hud at zurich.ibm.com --- +41 44 724 8573 --- SL: dr scofield

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080111/0936c996/attachment.htm