Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SAFE browser plugin URL handling / dynamic HTML on client side #37

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

happybeing
Copy link

I've been thinking about the plugin support needed for dynamic web apps and the result is this suggestion for how the browser plugin could handle URLs and enable client side scripting of dynamic HTML pages.

Death to the server!

PS The real reason for this PR is:
https://forum.safenetwork.io/t/maidsafe-code-bounty-program/4334/25?u=happybeing

@dirvine
Copy link
Member

dirvine commented Mar 28, 2016

@theWebalyst IS this still and active proposal Mark? If so we should try and progress a discussion in the next couple of weeks.

@happybeing
Copy link
Author

I'm not sure. I think it depends :-)

From memory I was trying to ensure that a URL could work along the lines of a dynamic website, for example:

http://domain.tld/some-path-to-a-template?post=123

I'm not sure if this is what is proposed, but think the existing launcher API might use # instead of ? as in:

http://domain.tld/some-path-to-a-template#post=123

In which case this causes a SAFE REST request for http://domain.tld/some-path-to-a-template (ie the URL up to but excluding the # and what follows), while the client side (JavaScript) can read the whole URL and so make a separate request for the appropriate content (by constructing a separate SAFE REST based on "post=123").

If I've understood that correctly, this is functionally fine and quite a neat solution. But one of the issues I was concerned about was page load times, particularly on first load. It remains to be seen what the latency is on SAFE network, and therefore how much of an issue this is, but the scheme as I understand it would mean a minimum of two sequential requests which effectively doubles the latency for a page that isn't in the local browser cache. I'm concerned that this will compare poorly with a current dynamic website where the whole URL generates a single request that is responded to by the server.

Obviously there are also many websites which load content dynamically (AJAX style) but I don't know enough about all this to know how these might compare.

Anyway, my scheme called for the ability to initiate multiple concurrent SAFE REST requests within a single URL, with the response data available in the browser client API (e.g. using promises). Doing this is not very elegant, so if SAFE network latency isn't an issue the '#' scheme would be preferable (simpler to understand and implement). But if latency means that dynamic websites are noticably slow to load I'm concerned about the impact this would have on their usefulness, SAFE adoption and the perception of the project. So, it depends :-)

@dirvine
Copy link
Member

dirvine commented Mar 28, 2016

I see what you mean here Mark. Lets leave this in place for a while longer and wait till we get some real world tests of response times when everyone has vaults in place. We can revisit this then and confirm there is an issue and if so use this as a place to bounce further ideas off of. Is that OK with you?

@happybeing
Copy link
Author

Yep, makes sense. Can't wait to see the thing fly :-)

dirvine added a commit that referenced this pull request Jul 25, 2016
Change RFC #37 to "active".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants