I have an ember application that I create like this:
window.App = Ember.Application.create({});
I want to do some background processing on a web worker.
How can I get access to the window object or some other global object in the separate web worker thread?
Short answer. You can't.
The only resources available to web workers are that which they load from JavaScript files using importScripts() or anything that is passed to them via postMessage().
You can however now pass Objects to them. They are serialized and de-serialized to JSON automatically.
Also, there is no access to local storage from the Worker.
Related
How can I access the client URL in a Web Worker? I can access the client and URL in a Service Worker with the Clients API, but I have not found a way to do that with Web Workers.
I need to know what page the user is viewing to conditionally change the data posted from a Web Worker. For separation of concerns, I can't handle anything on the client itself.
You can't. The Worker knows its own location, accessible through self.location, but it doesn't have access to the one of its creator.
The only way is to have your main thread to pass that info to your Worker, e.g through postMessage.
I have an app that runs service worker. I'm using sw-toolbox library for dynamic caching of URLs, but I want to create wrapper over sw-toolbox that provides getters and setters to my application for URL caching.
As service worker runs in different thread and my application running in main thread, so just wondering how to create a wrapper in Javascript through which my application can communicate with service worker and cache resources on-demand?
So far the Cache api is available from content, that means you can use it directly from your Javascript code, no need to run in the Service Worker.
Check this thread to find the resolution: https://github.com/slightlyoff/ServiceWorker/issues/698 You will be able to use caches from the window object.
Meaning you have all range of Cache methods to play with the content: https://developer.mozilla.org/en-US/docs/Web/API/Cache
Just another reminder, from Chrome 46, you will be able to store stuff just in secured origins.
From the Documentation, Cache API/interface is exposed to windowed scopes as well as workers.
You don't have to use it in conjunction with service workers, even
thought it is defined in the service worker spec.
It depends how your worker caches data, it it just uses the standard "Cache" API than you can just query cache object which is attached to global scope.
In this particular case Cache.match() is your friend.
I have a Node application with a number of workers that serve dynamic pages. Each worker needs to have access to a central object, which contains methods to find and cache information from a 3rd party API. This object will be on the master process so that the workers can easily communicate with it.
I would like to be able to access the cache and API methods easily, and get the response in a callback on the worker process. For example: if I wanted to get a user from the API (or cache if cached), I would call something like getUser('userID', callback) where callback is a function that would be called with the users details, or an error if one occurred.
Is there any simple ways that I can do this? or have I designed it badly? Is there a better way to share a single instance of something between multiple workers?
I have an ember application that I create like this:
window.App = Ember.Application.create({});
I want to do some background processing on a web worker.
How can I get access to the window object or some other global object in the separate web worker thread?
Short answer. You can't.
The only resources available to web workers are that which they load from JavaScript files using importScripts() or anything that is passed to them via postMessage().
You can however now pass Objects to them. They are serialized and de-serialized to JSON automatically.
Also, there is no access to local storage from the Worker.
Considering that PhantomJS isn't exactly node.js (so modules like deathbycaptcha2) are out as they use native requests, is it possible to simply open another instance of webpage and use it to send POST requests to the captcha API without affecting the other page instance?
Will this new page.open() retain cookies collected by the first page?
Will this new page.open() retain cookies collected by the first page?
Yes, there exists only one CookieJar for each PhantomJS process. So every page that you create shares the same cookies. Think of those page instances as windows or tabs in a conventional browser.
[I]s it possible to simply open another instance of webpage and use it to send POST requests to the captcha API without affecting the other page instance?
That's not so easy, since the cookies are shared. If you don't access the same pages you can safely create a second instance. If you want to access the same page in the second instance then you can spin up a second PhantomJS process through the child_process module (e.g. with execFile).
Considering that PhantomJS isn't exactly node.js [...]
True, but there are several bridges between PhantomJS and node.js such as phantom, node-phantom, nightmare, etc. You can use them to interface with PhantomJS and additionally call node modules that you want.