Setting up a server, where we can host documents to be displayed in the extension

[blackforestboi]

There are some pages currently in the extension, that will be updated fairly often, like the FAQ or the contributions page. If we now want to update them, we have to update the tool and also the version number. This is rather unsuitable circumstance.

The idea is that we put those documents all on a server and then implement them into an iFrame inside the extension. And in case there is no internet connection, the page is just cached.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[bohrium272]

Let's set up an endpoint on AWS(or RedHat?). I can make a Python Flask app that delivers the pages.

[blackforestboi]

cool. how would the versioning work then? Just uploading updated files via ftp?

[bohrium272]

Yeah. The client side would be an iframe. We can change the HTML whenever we want.

[blackforestboi]

perfect.

[bohrium272]

I tried using raw html files from the repository in an iframe. Except for the header and the left navigation pane, everything was in an iframe. However that messed up the css and the javascript files so it was not displayed correctly. I think putting everything in the iframe is the way to go.

[blackforestboi]

Does it automatically include the Css file? How would you be able to just separate the innerhtml from the raw file? did you create a new one or used the existing FAQ.html?

[bohrium272]

In the current FAQ.html, I took all the code from the div at line 184 and put that into a new html file. I replaced that div in FAQ.html with an iframe linking it to the new html file. It broke the page. So I included all the CSS and JS files from FAQ.html into the new html file, it still didn't work properly. Hence finally, I took the whole page and put that into a new html and henceforth into an iframe.

[blackforestboi]

and this way it works?

[bohrium272]

Yes it does.

[blackforestboi]

Cool :)

2 questions:

1. Why are the inner boxes so crammed togethre?
2. can we get rid of the visible frame surounding the iframe?

[blackforestboi]

and lastly. if we really make an iframe of the whole thing, we probably wont need an iframe. :) We could just load the whole page.

[bohrium272]

Looks fine now?

[blackforestboi]

What did you change?

Nope, not really ideal. Have you installed the plugin itself to see how it is looking now? There it is responsive so that its not too wide ad not too narrow.

[bohrium272]

There's a frameborder property of iframe which if set to 0 shows no border around the iframe. Along with that, I remove the div with class col-md-8 to make the section fill the width. It still is responsive.

[blackforestboi]

I put the col-md8 for a purpose of not being too wide. looks bad on even slightly bigger screens. My question was rather why it was so crammed together by just using the styles as they were. Why was it rendered that way on your screen? (Is it like that also with the current plugin?)

Also, as we use the whole page we might not have to use an iframe but rather a cache for the page, that is stored locally and as soon as a new update is available it would update it?

[blackforestboi]

(Is it like that also with the current plugin?)

can you make the screenshot for how the plugin looks on your screen? works also for chromium btw.

[bohrium272]

[blackforestboi]

Sorry, I mean the current one. The version from the chrome app store.

[bohrium272]

[blackforestboi]

Thanks :)

So why was the inner part so crammed before? Because of the iframe?

What happens if we now just link the whole page (https://cdn.rawgit.com/WorldBrain/Research-Engine/master/extension/assets/FAQ.html)? (Hint: i just tested opening the page, it then changes every link to be rendered by rawgit. which is suboptimal.

Also it somehow does not render the sidebar correctly :/

Seems like this approach is for now just a suboptimal work-around.

I think also for later purposes, having a server that can update these things is better. We might want to handle more data there as well. Gives us more flexibility. I have another few use cases for the server. For example to send out notifications to the extension. These notifications have to be entered somewhere anyway.

What do you think @arpitgogia ?

[bohrium272]

If that's the case then let's go ahead with the server. It isn't much of a hassle.

So why was the inner part so crammed before? Because of the iframe?

Yes that's probably the reason.

[blackforestboi]

ok good. Then the server it is:) Thanks for investigating!

[blackforestboi]

@dvigneshwer Ok what is missing here is:

• [ ] set up on AWS as described in the "server"-repo
• [ ] separate the inner part of the contribute.html page into a single HTML file
• [ ] use this html file and put it into the extension as an iFrame

Important:

1. Only the inner part of the contribute page should go into the iframe so without the sidebars, those should be the ones from the extension (the title can still be there)
2. Make sure all the styles and formats stay the same as they are now. In our first try there was a lot of distortion.

[bohrium272]

Adding to the discussion, we can use AWS CodeDeploy to automatically deploy a branch from a GitHub repository.