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

Thanks,

That's right, maybe it's not an issue if everything is handled inside the
app.
Some pages present a permalink button for exemple which allow sharing of a
resource.

We could also use a bookmark ontology and store it on the RWW instead of
the non-portable browser bookmark, and share resources urls to webid users
in a post to some kind of appendable inbox


Just wonder if the usecase of sending an url taken in the browser form and
send it to a friend by mail will be deprecated or not in the upcoming web :)


On Fri, Dec 27, 2013 at 10:42 PM, Niclas Hoyer <niclas@verbugt.de> wrote:

>  Hi,
>
> most of the mobile platforms actually don't present the current URL to the
> user at all (e.g. if you install an open web app [1] with Firefox for
> Android or on Firefox OS), because the SPA is treated equally as an native
> app without browser UI. Firefox nightly also supports to install these apps
> as kind of "native" apps on Windows, Linux distributions and OSX, running
> in a stripped down Firefox window without UI with integration into the
> program launchers of the system (e.g. GNOME dashboard).
>
> If one follows that path it would be okay to just ignore the URL
> altogether and present the "current" URL that may be bookmarkeable inside
> the SPA with its own UI.
>
> [1]
> https://developer.mozilla.org/en-US/Apps/Quickstart/Build/Intro_to_open_web_apps
>
> Regards,
> Niclas
>
> Am 27.12.2013 22:15, schrieb Sébastien Lorber:
>
> 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
>
>
>
>
>