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

[Teravus Ovares]

:D  Also, a reiteration,
Using the -loginURI  and the -loginpage, the current release client and
windlight can log into a recent version of OpenSim.

Teravus Ousley

On 1/12/08, Dr Scofield <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 --- +41 44 724 8573 --- SL: dr scofield
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080112/e0697864/attachment.htm