Talk:Viewer URI Name Space

Does this mean that no region can be named 'app'? Phoenix 17:27, 23 July 2007 (PDT)

Yes, no region can be named "app". I had to pick some prefix, this one seemed reasonable. Unfortunately, also any string starting with secondlife:// can be legally parsed as a region name. James 08:54, 24 July 2007 (PDT)

I think this is a really bad direction to start down -- it artificially limits our usable space. I think we should instead make a new protocol for local resources, or make a more general url syntax. For example:

slclient://locally/available/resource

or

secondlifegrid://localhost/locally/available/resource

Phoenix 09:39, 24 July 2007 (PDT)

I agree with Phoenix here. Extending the secondlife: scheme is a mistake, since it's already well defined what it means:

"Via the Second Life protocol I am access Region Foo at x,y,z"

Mozilla uses the uri scheme chrome for "locally accessable resources that are accessed without knowing their precise filesystem location".

secondlife:// as a region name is actually okay. In URI form, it would be secondlife://secondlife%3A%2F%2F/1/2/3

From what I can tell, something like slchrome:// or slui:// would be better.

Mark 10:07, 24 July 2007 (PDT)

Yes, I see your point and agree. I initially chose secondlife:// for expedience, as the installer already registered it on all platforms, the embedded mozilla already had callbacks for the links, etc. But we need a different protocol for this type of command.

I'm going to use slclient:// because the word "client" is probably more understandable to an end user (who might see the raw link in a browser warning dialog) than "chrome" or "ui".

James 10:30, 24 July 2007 (PDT)

---

Well, while it is ugly, and unfortunate, I don't think a "one-time" fix of inserting "/app" at the top level is that bad. I think there are plenty of downsides to creating another scheme identifier. A way to make this more palatable is to fix the top level of the path, so whereas before you had:

secondlife://Obscure/123/98

you'd now have:

secondlife://location/Obscure/123/98

The old one would be deprecated, and yes, regions with the name "app" or "location" or whatever else we put a the top level wouldn't work with the old style.

The primary reason for having a scheme is that it is the way to get an operating system to open up another application with a class of URIs. Hence, everything in such a URI namespace is really the name for something the running viewer can do. We shouldn't use the secondlife: scheme to address elements of our network at all. Hence, I don't think the need for a top level '/localhost' in the examples above.

Since the scheme is entirely for the purpose of directing the viewer, it is reasonable to think of all those resources named as actions or concepts in the viewer. In otherwords, the URI

secondlife://event/<uuid>

should be though of as the viewer's concept of that event in our system. And this should conceptually distinct from, say:

http://services.agni.lindenlab.com/event/<uuid>

which would be a reference to the event resource back at the grid.

As such, such URIs really should only imply viewer actions on those objects: I could see secondlife: URIs that open an event in the viewer (but one wonders why?), but not one that creates an event that way. For the most part, I think we should be steering such functionality to the web services.

Lastly, a big problem with the URI tree proposed is that it puts all content into global name spaces by type. In particular:

secondlife://app/parcel/<uuid>

implies that one can reach ANY parcel that way. This is bad as it forces us to think in terms of a single global list. Much better would be

secondlife://app/grid/agni/region-by-name/Obscure/parcels/<uuid>/view

Though, admittadly, the "/grid/agni" part may be overkilll.... but perhaps not...

ZeroLinden 10:38, 24 July 2007 (PDT)

---

The primary motivation for this is to make clicking on links in a Find All search results page (output by Google Search Appliance) show SL UI with details on that data. Even if we move that data display to HTML, we'll still need a way to have links/buttons that offer teleports, open the IM window, etc. So we need a commmand format.

At the time the parcel links in the HTML pages for search are made, I do not have access to the region name or other information other than the UUID of the parcel. For example, top picks only store the parcel UUIDs. I could thrash the database during the static HTML page generation for search to look up the region names for each parcel UUID I encountered, but that seems a waste of effort to me.

I could imagine having special links that opened, say, the event UI as a useful way to share references to information in our system, on outside web pages, in our own IM, and in tutorials. Since I have to do some internal link management for search, it seems reasonable to me to expose those URLs to the outside world.

I would prefer to reserve the words "event", "classified", "place", "parcel", "agent", "resident", "person" and "group" as being invalid region names. secondlife://agent/<agent_id> looks cleaner to me than secondlife://app/...

Without slclient://, all these links are working now. Do we really want slclient://? Also, our entire system for places/events/top picks currently stores only parcel ids. I'm not thrilled about embarking on a huge refactoring of this system just to get search to work.

James 10:56, 24 July 2007 (PDT)

Non-Standard

Bah! I can't believe I didn't notice this before: Our syntax doesn't follow the recommended syntax for path based URI schemes! It should start with three slashes, not two, like file: does. This is because the thing after the double slash is the authority section, containing a hostname and port (and other stuff optionally as well...).

It might be worse - depending on one's reading of section 3 of RFC 3986, our use of double slashes without an authority section could be seen as illegal. Of course, we could claim that the region name or "app" was the authority (and hence host).... but I bet w don't follow all the proper conventions for host names. Fie!

See http://tools.ietf.org/html/rfc3986

ZeroLinden 15:33, 6 September 2007 (PDT)

---

James writes:

Looks like secondlife:/// is what we want. My only concern would be that crappy IRC clients and other programs that attempt to automatically identify URLs in text would choke. Colloquy does it correctly. I will try other clients in the office tomorrow.

Changing to secondlife:/// is trivial in my code. Any reason I shouldn't just do it?

---

Well, we have to continue to handle the existant URLs. So perhaps we take this moment to "fix" the whole scheme:

secondlife://<region name>/<x>/<y>/<z>
 -- old style, still accepted

secondlife:///viewer/go/<region name/<x>/<y>/<z>
 -- new style, with well defined rules about encoding region names

secondlife:///viewer/agent/<agent_id>
secondlife:///viewer/group/<group_id>
 -- etc., the controls being added for search
 -- (that these are an implicit "open a floater on this item" verb is a little odd,
  what's the URL for "IM this line of text to this agent"?)

secondlife:///viewer/login/...
 -- the login work for web site auth.

ZeroLinden 08:57, 7 September 2007 (PDT)

---

I will of course support legacy URLs. I see no strong reason to switch from "app" to "viewer". Likewise, my initial syntax for agents/groups/etc. is of the form:

 secondlife:///app/agent/<agent_id>/about

Where "about" is the verb. Thus we can add "im", "offer-teleport", etc.

Any reason I should not just implement secondlife:///app/agent/<agent_id>/about ?

James 09:57, 7 September 2007 (PDT)

Question About secondlife:///app/chat/channel/text

I tried "secondlife:///app/chat/0/Text" And That Worked But How Do You Get More Than One Word? I Would Like To Use It In A Hud For Staff At A Club When The Hud Will Fill In The First Name Of The Person Into Some Standard Greetings And Information. But Escaping The Text And My Character Will Of Course Say It With It Still Escaped. Ive Tried A Few Ways Hoping Something Would Work But Get Only The Forst Word Or Nothing At All, Its A Rainy Day Project

 llOwnerSay("Click To Speak:  secondlife:///app/chat/0/Testing, Testing 123");//Says Testing
 llOwnerSay("Click To Speak:  secondlife:///app/chat/0/" + llEscapeURL("Testing, Testing 123"));//Says Testing%2C%20Testing%20123
 llLoadURL(llGetOwner(), "Click To Speak", "secondlife:///app/chat/0/" + llEscapeURL("Testing, Testing 123"));//Nothing Happens
 llLoadURL(llGetOwner(), "Click To Speak", "secondlife:///app/chat/0/Testing, Testing 123");//Nothing Happens

Adi 07:12, 8 August 2010 (UTC)

URL Escaped?

Someone tell me if I am testing this wrong, since this article says it is URL escaped.

If I click: secondlife:///app/chat/0/foo%20bar

The result is as follows:

[11:46:03] kizmut Smit: foo%20bar

Kizmut Smit 18:47, 23 August 2010 (UTC)

---

Example Corrections

I was trying the old script on here and noticed it does not work it either came back with Syntex Error or said Object: Touched by (nobody).

Original Code

string Who(key id) {

   return "secondlife:///app/agent/" + (string)id + "/inspect";

}

default {

   touch_start(integer n)
   {
       llSay("Touched by " + Who(llDetectedKey(n)) + ".");
   }

}

Reworked Code

string Who(key id) {

   return "secondlife:///app/agent/" + (string)id + "/inspect";

}

default {

   touch_start(integer n)
   {
       llSay(0,"Touched by " + Who(llDetectedKey(0)) + ".");
   }

}

Kobra Stein 11:43, 12 January 2013 (PST)