View source

Does this mean that no region can be named 'app'? [[User:Phoenix|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.  [[User:James|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

[[User:Phoenix|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.

[[User:Mark|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".

[[User:James|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...

[[User:ZeroLinden|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.

[[User:James|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 <b>three</b> slashes, not two, like file: does.  This is because the thing after the double slash is the <i>authority</i> 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 <i>could</i> 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

[[User:ZeroLinden|ZeroLinden]] 15:33, 6 September 2007 (PDT)

----

<i>James writes:</i>

Looks like <code>secondlife:///</code> 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 <code>secondlife:///</code> 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.

[[User:ZeroLinden|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 ?

[[User:James|James]] 09:57, 7 September 2007 (PDT)