Is there a limited bandwidth for the Dropbox API (JavaScript)? - javascript

I want to store audio files of a podcast in my Dropbox for showcasing them on a smaller static Website.
So far I tried using public links to each file, but reach the bandwidth limit of these quite fast, because everytime somebody reloads the page that takes around 500 MB.
I thought about using the Dropbox API for accessing the files, but are there the same limits for the API?

Maybe no, you can try contacting their support team.

Dropbox links have bandwidth limits. You can find more information here:
https://www.dropbox.com/help/4204
This does not apply to authenticated (non-link) access though. For example, downloading files via dropbox.com or via the API /2/files/download. That probably isn't a great solution though, as it requires an access token. You may be better served by a normal CDN.

Related

Is it possible to using web api and open a local folder? [duplicate]

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!

Google CDN servers hosted libraries VS locally hosted

Is there a difference when we use files that are already stored somewhere(like Google hosted libraries or fonts) than the ones that are stored on local servers for our web pages, like differences on performance perspective?
Yes, there are a few differences. In most of the scenarios, your page will load much faster because:
If your browser already has a cached version of the library for some other site, it won't load it again.
Your browser may connect to Google or other CDN servers simultaneously, which may not happen if you are loading from your server.
The latency in getting the file from a Google server is almost always significantly shorter than with your server.
You will also have reduced load on your server.
The scenario where you may want to host on your site is if you are serving content for countries where Google, Google's CDN or similar are blocked.
Yes, these is small difference exists.
Modern browsers has limit, for example: no more than 4 parallel downloads from one domain. So, if you will use fonts from Google CDN servers, it possible, page will load little bit faster.

Some questions about HTML5 FileSystemAPI

I'm a first time user, just in the initial stages figuring out if this is going to be useful for me, so forgive any naive questions. I'm using Google Chrome.
Here's my use case -
The user needs to store some information to my application(web based) which may include paths to some files on his system. When the user comes back to access this information via my application, he should be able to click on the links that point to these files on his local disk and open those files.
Now, we know that browsers will not allow this due to security concerns.
I had the following questions
The description for HTML5 FileSystemAPI says that this will allow us to access files from a "sandboxed" section of the users disk.
Does that mean that the files that my user wants to read should only originate from a specific folder on his disk?
Do we get to decide what that location would be? File browser access to Chrome's sandboxed filesystems - i get the idea from this question that chrome decides that.
I would appreciate if someone could throw some light on this. Thanks guys.
AFAIK, the FileSystem API doesn't provide access to files outside the sandbox and the sandbox's location is imposed by the browser. You can use HTML5's File API to let the user upload data, and then store this data using the FileSystem API. However, I don't think this is what you want.
Unrestricted access to a user's filesystem is only possible through a Java applet or another plugin.

If I upload a new version of a javascript file to Amazon S3, should I expect browser caching problems?

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.

any free service to use as HTML5 offline cache link?

I tried using Dropbox links in my cache manifest, but it didn't work.
I tried NOT using cache manifest and simply:
<audio src="dropbox url" autoplay="true"></audio>
It doesn't play the sound either. If I point src to a file within the project or on the hard disk, it works. Are there any free services for hosting such things?
I don't know of any free and legal services for hosting audio content. I'd recommend looking into cloud-based storage options (AWS S3, Rackspace Cloud Files, et cetera). They typically have a cost based on the amount of files you have stored and the amount of data transfer per month.
You should be able to use external URLs in your cache manifest. However, it may be possible the URL you're trying to use has response headers that prevent it from being used in such a way.
You mean something simple and FREE that provides 100gb storage and 100gb traffic with ftp-access?
See sites like http://www.100gb.co/. There are a lot more of those kind of services, just USE GOOGLE! Think about it.. what kind of $%^&* would pay anno 2012 ?!?
You could also use services like sound-cloud. The main difference is that you don't link to the bare *.mp3 file anymore, but to a flash file.
Warning: just make sure you legally own the stuff you post. For instance, when I rip the albums from our band and post them online, I can do so, I co-wrote/own the material. It's just like taping: mp3 can never sound as good as the real full cd. Impossible.
Good Luck!!

Categories

Resources