Re: Running an RWW app on an iframe?

<iframe> (or embed) sounds like a good idea.

did a quick search: 
http://stackoverflow.com/questions/6784263/iframe-with-bookmarks-without-the-main-browser-jumping 
http://stackoverflow.com/questions/20441856/how-to-create-the-bookmark-of-the-iframe-content

Bookmarking can be sorted out…

There’s a bunch of similarities to mobile apps; it’s just html5/js (backend graph/RDF not MySQL) 

Haven’t done enough thinking to consider the manifest use of sparql queries yet. 

there’s a .known/ theory i’ve seen somewhere.  i imagine user-session preferences might have something to do with that? 

have you considered versioning, master/derivatives, management of potentially large sets of versions (many may replicate) and preference sets around different document / file types?

ie; heritage application might upload a 200-600MB TIFF file, with embedded .meta - then require that ‘master’ (or preservation copy) to be stored in archive; followed by the creation of a bunch of usable derivatives. 

then perhaps the senior / elder who made the tiff file didn’t know anything about colour correction; so, another contributor fixed up the file, generates a bunch of imagemagick RDF / metadata (re: settings for colour correcting the original file) and another set of derivatives are made this time with different creative commons attributes (meaning, it’s been a little more produced - the dublincore metadata structure changes).

RDF is cool for many good reasons. as long as it’s available in the RWW-Server though, i’m not sure it matters how clients are powered?  perhaps other than for community purposes?  it’s so early, if we’ve got MS vs. Netscape on JS Definition like debates; we might not help the ‘movement' we’re spending time / effort on defining.   http://data.fm/ gives a bunch of standardised request / response - interface standards.  Perhaps whether it’s one platform or another, competition helps grow; but developing baseline standards needs cooperation? 

The other issue perhaps is uptake / encouraging people to ‘dip their toes in the sparql’ ;) -  there’s a bunch of php people out there, with more experience on html5/LAMP than Java/scala (or python). 

hoping that makes sense to people? 

tim.
 
On 3 Feb 2014, at 9:38 pm, Sébastien Lorber <sebastien@stample.co> wrote:

> 
> Hi
> 
> 
> Imagine the following scenario:
> - User is using a browser
> - User receives an RDF resource URL
> - User opens the RDF resource in its browser
> - This makes a request to our server (rww-play) with a header "Accept: text/html, */*" or something similar...
> 
> 
> 
> In rww-play we are using some generic platform code. We don't serve RDF data to a browser unless he explicitly ask for it. So in this case we load an html file and js code that will refetch the same url again, this time asking for RDF format.
> By looking at what's inside the RDF we can choose through a mapping an appropriate RWW application that can decently render the RDF graph. 
> Idealy it would be nice that an user could store in its own data which is app is the most appropriate for him to render this kind of graph. This is what Andrei has also done in ld-cal for exemple.
> Like on a regular filesystem/OS, one can choose to open a .doc with OpenOffice or Word, and can make the opening with Word the default...
> 
> 
> 
> This RWW application is loaded dynamically and has its own kind of libraries.
> The problem I see here is that as we have generic html / js code that fetches the graph in RDF form, then when loading dynamically the app there may be library conflicts or things like that.
> 
> For exemple if the generic HTML code is using RDFLib 2.0 and the RWW app is using RDFLib 1.0 it may (?) be a problem to execute this in the same html page.
> 
> Do you think it could be a good idea to launch the RWW app in its own full-screen iframe so that there's no possible conflict? What would be the problems?
> Some don't like iframes for good reasons like bookmarks or things like that.  But as we already have discussed there are already open questions related to bookmarks specific to RWW and they may need to be handled in the application directly instead of the browser address bar
> 
> 
> Is there another way, without using iframes, to provide a clean env to the RWW app?
> We are currently trying to use requirejs for that. But what I don't like with using require in the RWW app is that it's not the platform that guarantees a clean execution context (I mean, no JS lib loaded in the page), it is rather the RWW app that knows that the execution context can be dirty and try to bypass this.
> 
> 
> Also, maybe it's not such a big problem because once the RWW app libs are loaded dynamically, the generic code doesn't need to run again. I think the last loaded js libs override the previous ones so the RWW app may be able to execute correctly in any case.
> 
> 
> What do you think?
> 
> 
> 
> 
>