[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]

Teravus Ovares wrote:
> :D  Also, a reiteration,
> Using the -loginURI  and the -loginpage, the current release client 
> and windlight can log into a recent version of OpenSim.
yep, tried that, works :-) excellent work, teravus! would be nice to 
have just -loginpage working though :-)

    cheers,
    dirk

>  
> Teravus Ousley
>  
> On 1/12/08, *Dr Scofield* <hud at zurich.ibm.com 
> <mailto:hud at zurich.ibm.com>> wrote:
>
>     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 <mailto:hud at zurich.ibm.com> --- +41 44 724
>     8573 --- SL: dr scofield
>
>     _______________________________________________
>     Click here to unsubscribe or manage your list subscription:
>     /index.html
>
>


-- 
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/20080112/2e59b026/attachment-0001.htm