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

[Argent Stonecutter]

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.

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.