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

[Dr Scofield]

Argent Stonecutter wrote:
> On 2008-01-11, at 15:27, Dr Scofield wrote:
>> Argent Stonecutter wrote:
>>>> 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 !
>>>
>
>>> Except it isn't. That addresses a location on a map that provides a 
>>> link to a location in the Second Life grid. The SL client does not 
>>> understand http://slurl.com, it understands secondlife://
>
>> that' what i wrote: secondlife: is directed at the client and 
>> supposed to control it. it's not meant to address a location on the 
>> SL grid.
>
> The only component on your computer that can address a location in teh 
> second life grid is an application that communicates to a second life 
> server.
>
> The only URL that can address a location in the second life grid is a 
> URL that is handled by an application that communicates with a second 
> life server.
>
> An "SLURL" is no more a link to an address on the second life grid 
> than a link to Google Maps is a street address.
>
> Also, an SLURL adds an extra and unnecessary trip through HTML in 
> resolving a name, and requires having an HTML parser to get the *real* 
> address out of the page. It's like sending someone your address 
> through a FAX-email gateway because of course everyone has OCR software.
>
> Now you could add a "grid:" URL, but that kills legacy secondlife: 
> URLs that people are already using. Doing that without a really good 
> reason is just as unfriendly as changing the way 
> llSetPrimitiveParams() works.
>
>>> The best solution would be to take advantage of DNS and URL formats. 
>>> Since the new login code is being postponed, it *is* subject to 
>>> change, if necessary, because there's no longer any legacy code that 
>>> isn't going to be modified anyway (when it's revisited) that depends 
>>> on it.
>
>> personally, i don't quite like the DNS approach: at first i thought, 
>> hey, neat idea --- but coming to think about it, i think it's not 
>> really as it requires me to be able to add TXT records to my DNS 
>> entries. while i know how to do that and can actually do that, there 
>> are situations where that is not the case (joe's garage grid, DNS 
>> policies within some companies, etc). i'd propose to instead have one 
>> indirection level there: retrieve via REST from the hostname the 
>> login server. we can have the DNS solution as well.
>
> There's always a lot of pushback like this whenever TXT entries come up.
>
> 1. This is why they're not supported, because people don't think they 
> should be used, because they're less widely supported.
>
> There's enough applications that use TXT records these days that this 
> shouldn't be an issue.
i'm not against TXT, just would like to see the possibility of plain A 
working as well.
>
> 2. I already covered that:
>>> First, the host part of the CINS URL would uniquely encode the 
>>> location and the grid. The usual TXT record meta-syntax would make 
>>> it easy to parse out the grid name without dealing with the TXT 
>>> record lookup if you REALLY needed to:
>>>
>>> Grasmere._grid.secondlife.com
>>>
>>> The "local_part . _type{1+} . path" makes "._" a unique separator 
>>> for the local_part.
>
>
> 3. Second alternative, do a query for either TXT or A. If you don't 
> get TXT, use the A record for the server.
how about, try A then TXT? isn't SMTP working that way?

    cheers,
    dr scofield

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