Problem definition:
Server is an embedded system with no access to Internet.
Each server is managed by web interface which uses JavaScript.
Each server has a local copy of JQuery library.
Clients (browsers) are connected to embedded systems (servers) via a very slow connection.
Clients have the latest browsers (HTML5, CSS3, JavaScript 1.8.5)
Clients are not connected to Internet either.
Clients can't access multiple servers at the same time (servers are in distant locations and most probably a client can only access one server and nothing else, but later that day the client may go to another location and connect to another server).
Each server has an IP address (not necessarily in the same range) and no DNS name.
Every time the client connects to an embedded server, it fetches all the files including the huge JQuery library (huge=~90KB)
Question:
The JQuery library is too big for this slow connection but one-time download is acceptable. However, we don't want the clients to download it every time they connect to each new server. The JQuery on all these devices is the same. But apparently the browser cache is domain based. How can we cache the JQuery library so that the client doesn't have to download the JQuery every time it connects to a new server?
just link to it in one place...
for example, if you have a single server, http://1.2.3.4/ that you want to designate as your CDN, put jQuery on it, and link to it in your scripts using <script src="http://1.2.3.4/jquery.min.js"></script>
you could link it to the ip in your link tag. The server does not have to have access to that access or anything, and so all the clients will geht the jquery from the same server all the time and so it is cached.
Here is a simple solution: All your customers must edit their /etc/hosts file (Google for where you can find it on Windows) and put a line like this in their config:
1.2.3.4 jquery-from-closest-server.com
Each client must figure out the closest server which has jQuery and replace 1.2.3.4 with its IP address.
In your HTML code, always use the link http://jquery-from-closest-server.com/jquery.js
To be safe, you may want to register jquery-from-closest-server.com for those customers which do have Internet access.
When the browser asks for the file, it will use /etc/hosts to resolve the IP address. Since the domain name will be the same for all your embedded devices (changes in the IP address are ignored by the browser), the script will be downloaded once for all clients.
Note that this means you can never upgrade to a newer version of jQuery. The problem is that you'd have to replace it on all embedded devices at the same time because there is no telling from which server the customers are downloading it from.
If that bothers you (and it will in about four months after you discovered the first serious bug), here is another solution: Instead of serving the HTML from your embedded device, distribute a static web app (a set of HTML files and JavaScript) which customer can install in their desktop. Use AJAX and iframes to replace parts of the static web app with data from your embedded device.
Advantages:
very fast (no downloads at all)
only little code on the embedded device
easy upgrade strategy
No deadlocks when you need to upgrade either the embedded devices or your controller app.
[EDIT] PS: Consider to compress jQuery with gzip. That leaves you with a 33KB file. All HTML5 browsers can decode compressed files, you just have to tell them by setting the necessary HTTP headers.
Apparently there is no standard way to include JQuery in our project so we chose to replace JQuery with a smaller similar library. These are the options:
JQuery mobile is a better fit for our project since it has a smaller size and can do almost everything we need from JQuery.
Zepto.js is also another suitable replacement.
JQuip is a stripped down version of JQuery that can help our specific project.
Related
We are currently looking at porting a enterprise silverlight application over to html5. The major roadblock that we have hit is the ability to open files from the user's local disk. Currently they have a document library which just links to files on their computer that they can open from within the app and view or print out. All that I read is that you can only access the local sandbox of the web app with the html5 file api's. We want to load these files from code.
Does anyone know of any workarounds to this?
Thanks
There is no way for html5 to access local file without user selection. But FSO: FileSystemObject works for IE and MAYBE could be regarded as a work around. But still there are some requirements to meet.
It is possible to use chrome's filesystem API to access files on a users local filesytem. So you'd have to be willing to make this a chrome only application.
Using java you can create a "Signed" applet which has access to the local filesystem. (if the applet is signed you can request filesystm permissions)
then there is a tutorial for accessing methods of your java code directly from javascript here: http://docs.oracle.com/javase/tutorial/deployment/applet/invokingAppletMethodsFromJavaScript.html
you should be able to perform something similar from silverlight.
There is no workaround in pure HTML5/Javascript. You need the use of plugins, such as Java or Silverlight (maybe you shouldn't port it after all). As for workarounds, HTML5 gives you an easy way drag and drop multiple files that you could transfer on the server and then display back to your users. Another workaround would be to install a custom agent (a software with only a tray icon) that would send the information about the current user "document library" to server and then again, you could display it back to the user.
Note: I've heard somewhere that browsers will eventually stop supporting plugins. http://www.howtogeek.com/179213/why-browser-plug-ins-are-going-away-and-whats-replacing-them/
Ya, I agree with Markain. However, if you were to limit your audience solely to chrome users, I daresay, you would most likely use some of your users. If Huazhihao is right, then your number of leaving customers should decrease but users who regularly use firefox won't be happy. Overall, I think that this will not work. Otherwise, there would be too many websites that trashed your hard driver (or at least wherever you have the rights to edit/delete files). I think it would be best if your product was setup to synchronize the file whenever an internet connection was detected and a change was made to the file. That way the user would not need to visit the website whenever the file was uploaded. If this is some kind of an error file, then it would be most beneficial if you were to make a link in the application that when clicked, would upload the file to the website and the website were to do whatever was necessary. If this is a purely online thing, then I don't see what business you would have looking through other peoples' files =-). Hope I helped!
I have a website hosted in ISS (can be other) that loads when it's called on localhost but not from extern :) like: http://:8081/Website.html.
The verification whether the website is called from localhost it's on the client in a js script that I can’t modify as it’s encrypted.
So I was thinking at two options:
Develop an ASP application that has a remote desktop connection to the machine that host the website (not some many example on how to).
Maybe configure the IIS configuration (didn't found how)
I'm out of ideas
Do you have any other solution or can you point on how can I do one of the above?
I have tried the WinForm solution from here: https://www.codeproject.com/kb/cs/remotedesktop_csharpnet.aspx and it doesn't work. And I prefer a website.
Updates:
The only working solution that I have for now is to configure a Remote Desktop Services (Web Access) as I hosted the application on Server 2008 R2. Then I only shared the browser that has the localhost page as default page
The javascript files are all minified and encrypted, meaning that if I search localhost as a word in all the files, nothing shows up. So fixing the client will be hard.
Is it possible to create a new Site Binding on IIS and access the site using the binding hostname? This requires your network DNS to register the hostname to the IP Address.
I assume you are dealing with encrypted(???) javascript that is hardcoded to display DOM only if it is loaded from localhost.
If by encrypted you mean minified you should still be able to find reference to "localhost" and modify javascript in minified version. If it is really encrypted by a wrapper of third party javascript library then I would suggest you to rewrite javascript. I mean how can there be any quality code in javascript code that is hardcoded to load only from localhost?
Fix the client and stop exploring other solutions like remote desktop connection. None of them are practical and sustainable solutions.
I think you need to use WebRTC, but it's supported for Chrome and Firefox. It allows two users to communicate directly, browser to browser using the RTCPeerConnection API.
There are two ways to call bootstrap's css and js files.
From CDN
From root file
My question is what way is the best way to work.
This question is essentially "Should I use a CDN?".
The answer boils down to the following factors.
You will need an internet connection all the time, even to test your code.
If you're on the move and don't have an internet connection, or one of your clients doesn't have one when you're demoing your code, then you're in trouble if you're using a CDN.
The CDN will most probably be faster.
CDNs are designed for the sole purpose of serving files, fast. Most of the time, there are several mirrors serving the content, so files can be served fast to users around the world. Also, if you host it from your own domain, you might also include several cookies every time you serve the file, while the CDN will not.
The CDN might go offline.
This is obvious, but it's a concern nonetheless. Check the reputation of the CDN you're planning to use.
Your bandwidth usage will be minimised if you use the CDN.
If you host your site up somewhere, and your host has a limit on the amount of data it will transfer for you, commonly called 'bandwidth', then a CDN will help, since it won't count against your usage.
Keeping these factors in mind, the final choice is yours. However, for JS at least, I recommend using a CDN with a local fallback. An example done using jQuery can be found at https://stackoverflow.com/a/1014251/2141058.
The CDN serves all the file for you, and will probably be faster than hosting them yourself. However, all you clients must have an internet connection. If your client will have an internet connection (if you are just writing a normal website), you should probably use the CDN.
If your client might not have an internet connect (if this site is internal to a company network) you should serve the files yourself, as your clients won't be able to reach the CDN via the internet.
A foundation of a Content Delivery Network is that a different url/ip address then the primary domain of your website can receive client requests and response with resources.
This means the client's browser can and will make requests for resources that are from different urls/ips in parallel. So when you have a js file on your website, say www.mywebsite.com/site.js, the client's browser will request this resource and queue up the next resource, if the resource is from a CDN, aka a different url/ip, the client's browser can make a request to a different server in parallel. So if you are requesting, cdn.bootstap.com/boostrap3-min.js, this resource can be downloaded to the client without waiting for www.mywebsite.com/site.js to finish downloading to the clients browser.
So this means the overall website load time will be faster. but will it be human perceivable faster? If this is a website built for mobile devices then you may take advantage of a CDN because you need to optimize load times whenever you can. If the primary use of this website is a desktop website, with mild traffic, in a geographic region where broadband/decent connections is common place, it is not really worth having a CDN unless it is your own CDN server.
The bootstrap CDN server cannot be relied on, it is not part of your infrastructure. You should not trust that those that maintain the Bootstrap CDN will always have it up when people are going to your website. Sure, most likely, the CDN will be up and there is never an issue but if the Bootstrap CDN where to go down and your website doesn't look right or doesn't even work...You don't have the level of control you should have over the situation.
Also, using a CDN to a different domain and IE9 and IE10 and iFrames can cause issues, I wrote about this in my blog here:
http://www.sandiegosoftware.net/blog/script5-access-is-denied-error-in-internet-explorer-loading-jquery/
Use your own CDN server with a subdomain of the primary website domain or don't use a CDN is the best rule of thumb.
We have a large number of people (10k+) who return to my clients' sites on a regular basis to use a web app we built, improve, and host for them. We have been making fairly frequent backward-incompatible updates to the web app's javascript as our app has improved and evolved. During deployments, the javascript is minified and concatenated into one file, loaded in the browser by require.js, and is uploaded to and hosted on Amazon S3. The file name & url currently doesn't change at all during updates. This last week we deployed a major refactor to the web app and got a few (but not a lot) of reports back that the app stopped working for some people, particularly in firefox. It seemed like a caching issue. We were able to see it initially in a few browsers in testing but it seemed to go away after a refresh or two.
It dawned on me that I really don't know what browser-caching ramifications deploying a new version of a javascript file (with the same name) on S3 will have and whether this situation warrants cache-busting or manipulating S3's headers or anything. Can someone help me get a handle on this? Are there actions I should be taking during deployments to ensure that browsers will immediately get the new version of a javascript file? If not, we run the risk of the javascript and the server API being out of sync and failing, which I think happened here.
Not sure if it matters, but the site's server runs Django and the app and DB are deployed to Heroku. Static files are deployed to S3 using S3Boto via Django's collectstatic command.
This depends a lot on the behaviour of S3 and the headers it sends when requesting files on S3. As you experienced, browsers will show different caching behaviour - so the best option is to use unique filenames.
I would suggest to use cachebuster hashes - in this way you can be sure that the new file always gets requested by browsers and you can use long cache-lifetime headers if you host the files on your own server.
You can for example create a MD5 hash of your minified file and append it (like mycss-322242fadcd23.css). Or you could use the revision number of your source control system. You have to use the cache buster in all links to this file, but you can normally easily do this in your templates where you embed your static resources. Depending on your application, you could probably use this Django plugin that should do this work for you.
I wrote a simple web server that takes the public link to a google document containing image urls and names and outputs a print-friendly HTML photo directory with its contents.
I created it for a volunteer organization that I will no longer be able to stay involved in. I need to pass on the ability to generate that directory to my successor.
I'm not confident that I can trust myself to maintain that web application for the long term the organization needs. I'm hoping that instead I can change it to a self contained program, that members of the org could email around to whoever needed to generate the directory.
My first thought was to make a .html file the could open in a browser but I can't download the CSV data from google with Ajax, because it is cross domain. After googling there doesn't seem to be a way around this.
Is there a straightforward framework? I would guess I could do it with Adobe AIR, but I'd prefer something that simply removed the cross domain security feature.
I could take the time to embed a UIWebView into a Mac app, but since I want to write the app primarily in HTML, I'd have to create a bridge to let the web view make a cross domain request anyway right? Also it's not cross platform.
Any other ideas? How can I package my app as a desktop application instead of a web service?
You can get around the cross domain XHR using flash. CrossXhr can do it from apps served by regular http servers. I've never tried it with a static, file-served webapp. Follow the instructions here:
http://code.google.com/p/crossxhr/wiki/CrossXhr