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

[Dr Scofield]

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.


the complete log of the AWGroupies meeting is available at 
http://wiki.secondlife.com/wiki/AWGroupies-2008-01-08.

    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/20080109/ead1a675/attachment-0001.htm