Solving the "Deep Linking" (bookmarkability) problem in RWW for single page applications

Hi all,

I'm working with Henry and I'm trying to build a Single Page Application
(SPA) that can navigate to the RWW.
I can't find an elegant way to handle deep linking (possibility to
bookmark/share the url) without reloading the whole page, which is not
really a modern user experience.



Suppose I have an RDF resource located at http://sub.rwwserver.io/resource

The server actually detects that it's a browser with Accept prefering html
content, so it sends some generic html page with some JS in it that will
refetch the resource in RDF format, and startup the SinglePageApp to render
that RDF graph.

This is a SinglePageApp so we aim to not refresh the page and reload the
app as we navigate through the RDF graphs.


If this resource is a foaf profile:
http://sub.rwwserver.io/profile
Then on my SPA can eventually click on a friend of this foaf profile
(foaf:knows) which will lead to a rendering the friend data, on which you
can also click on one of its friends...

When rendering a friend, as we are in a SPA, the url remain
http://sub.rwwserver.io/profile
So if I want to bookmark or share the friend's page, I can't simply use the
browser current url.


If the rendered friend is part of the subdomain, with HTML5 history
pushState (or History.js) it is possible to modify the url and add an
history element.

So if the first user to render is
http://sub.rwwserver.io/profile1
And then we render its friend
http://sub.rwwserver.io/profile2
it is possible to change the current url to profile2 url without reloading
the page, even if the loaded page was profile1 url

But it's not possible to change the url without reloading if the url to set
is on another domain or subdomain. This is a security issue because if you
go to hacker.com, the site could change the url to yourbank.com and do some
fishing more easily.






So what is the solution to build modern JS RDF applications (SPA) and be
able to solve this deep linking problem?


We could probably change the url when the domain is the same, and redirect
to the new resource to render when the domain is different. That wouldn't
always redirect in many cases, particularly when the user navigate in its
own content for exemple.
But when dealing with stuff like navigating in social networks and foaf
profiles, it is very probable that the domain will often change between
users...







Js frameworks like Angular and Backbone usually use the url hash to perform
routing and solve this deep linking problem.

So I may be able to use something like that:
http://sub.rwwserver.io/profile#currentResource=http://otherrww.io/otherprofile
This way the url becomes bookmarkable and shareable, but the problem is
it's not really the true resource url that you share, and that many urls of
this kind (with hash) could point to the same resource url:
http://sub.rwwserver.io/someContent#currentResource=http://otherrww.io/otherprofile
http://test.rwwserver.io/#currentResource=http://otherrww.io/otherprofileThiskind
of defeat the original goal of an url I guess.

And if the first url is not available anymore, the link won't work, even if
the targeted resource is still available...



In addition, in my opinion, an user should be able to "choose" the
application he wants to open an RDF resource, as we can currently do in OS:
you can open .doc files with Word or OpenOffice, and have a default
prefered app. So many SPA could be used to render the same foaf profile.

If I choose app1 to render a profile, app1 may create a
#currentResource=url . and then I can send the link to someone.
But this other person may prefer to renderprofiles with app2, and maybe
app2 is not able to understand the hash semantics used by app1 for deep
linking, so it will render the original profile and not the profile in
#currentResource=url

This could eventually become a hacky standard for building RWW SPA, to use
the same hash semantics.
But another problem is ACL. If I share a link
originalResource#currentResource=url
then i have myself access to originalResource, but the other user may not
have access so the server won't load any SPA even if that other user have
access to the targeted resource

It could perhaps be done at the RWW server level (not sure, the url hash is
sent?) so that the server automatically redirect the client to the targeted
resource (without checking ACLs on the original) if it detects the
#currentResource=url fragment
But this doesn't solve:
- the RWW server could be down
- the url is ugly







Do you see any solution to this problem?


One solution could be to have some kind of equivalent of:
Access-Control-Allow-Origin: *
lke
Access-Control-Allow-History-PushState: *
implemented on browsers and added on RWW server responses, but it wouldn't
really prevent fishing because hacker.com could change the url to
http://rwwserver.io/myBankAccount and show credit card forms...
Maybe this can be used only on non-sensitive RDF resource url

What do you think?

Thanks