Slurls are great... they provide a fantastic way of integrating SL resources into the fabric of the Web (and in particular into Web 2.0 services). For example, by using a Slurl I can bookmark a resource in SL using del.icio.us - in fact, I can use a Slurl any place that I can currently use a URL.
However... and this is a pretty big however... Slurls suffer from exactly the same kind of persistence problems as URLs. Probably worse in fact, because a Slurl, by definition, really does identify a 'location' whereas a URL can (and often does) act purely as an identifier. If a resource gets moved to a new location in SL, its Slurl stops working as a useful link.
Take for example the Slurl for ArtsPlace SL that I've used in previous postings to this blog:
ArtsPlace has now moved from Pak to Eduserv Island. Going to the above Slurl now will land you bang splat in the middle of some kind of bondage cave - at least it did the last time I tried it. What you get to depends on what is currently at that location. There is no easy way of persistently linking to a resource like ArtsPlace in SL (as opposed to a particular location of the resource).
This problem can be solved by adding a level of indirection. (As everyone knows, all computer science problems can be solved by adding one level of indirection! :-) ).
A Splurlis a SL PURL (yes, I know that the acronym isn't perfect!). A PURL is a persistent URL, so a Splurl is a persistent Slurl. Splurls work by using the PURL system to maintain a mapping from each Splurl to the current Slurl for the resource in question. When the Splurl is used as the basis for a hypertext link, the PURL server issues an HTTP redirect to the current Slurl.
Here's one for ArtsPlace SL:
Easy huh?? The Splurl will work as a useful identifier and link for ArtsPlace SL for as long as the PURL system continues to work, irrespective of where ArtsPlace happens to be located. If for some reason I have to move ArtsPlace in the future, then all I'll have to do is update the PURL mapping table to the new Slurl.