html-next / skyrocket-original Goto Github PK

Workers should operate on a progressive-enhancement policy.

1. By default, messages are passed with stringified postMessage payloads.
2. If structured cloning is available, use it to transfer data.
3. If transferableObject is available, use it to transfer data.

Some Reading Material

• https://developers.google.com/web/updates/2011/12/Transferable-Objects-Lightning-Fast?hl=en
• https://developer.mozilla.org/en-US/docs/Web/API/Transferable
• https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/The_structured_clone_algorithm

Hi Chris, just a quick post to ask what is the status of this repo: very tempted to start playing with it but I really don't know at which stage you are. Ultimately I would like to be able to get ember-data operations (serializing / normalizing / saivng to / extracting from localforage) run in web workers.

Thanks a lot for creating this project,

L

This is similar to #4, but for specific cases.

On ui-threads a full app instance will be needed, along with full data-knowledge.

Ideally a ui-thread wouldn’t need to spawn it’s own worker setup.

Shared workers (#7) would solve a lot of problems, especially on mobile where you don’t want to spawn as many threads.

Data-sharing between threads is likely going to need to be done via localStorage lookups.

Since Interface is well defined and within our control (e.g. it’s not a wild west of worker interaction to account for), we could package worker.js twice, once for single-threaded use (as fallback.js) and once for within a unique worker (as <worker-name>.js

Since there's the theoretical chance the fallback would land on the main thread, we may want to add special backburner queues for scheduling and performing the operations.

A Worker has two parts –the worker, and the interface– each goes in a pod within /app/workers.

interface.js is a subclass of Skyrocket.Interface and allows a user to define the exposed API for the worker

import Skyrocket from "skyrocket";

const {
  prop,
  event,
  func,
  sendEvent
} = Skyrocket;

export default Skyrocket.Interface.extend({
  fetch: func(),
  find: func(),
  foo: prop(),
  bar: prop(),
  message: event(),
  notify: sendEvent()
});

This interface is instantiated when resolved for the first time and itself instantiates and manages Worker.

{
    stack: Ember.inject.worker('stack')
}

The instantiated interface can be interacted with much like a normal Ember.Object, except that all properties accessed and functions invoked return promises.

this.stack.find('foo'); // returns a promise

Properties must be accessed via get/set, and return a promise. This promise behavior should be debated, it is possible to create a syncing IO style binding for the property.

this.stack.get('bar'); // also returns a promise

Events can be listened to via on.

this.stack.on('message', this, myFunction);
this.stack.off('message', this, myFunction);

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

All workers will be provided with a standard interface to manage IO. This interface is the worker side parallel to #1 responsible for syncing interface properties defined with prop, executing functions defined with func , emitting events defined with event, and sending back events triggered with sendEvent.

To reproduce:

clone the repo, npm install && bower install, run ember test.

You'll see a series of errors related to importing missing modules.

All you need to do to make all the tests except one (the one which imports the module that imports ember-runtime) pass is open index.js and comment out the thing the import of ember-runtime.

Ping @rwjblue.

You may want to read the ReadMe section on Terminology before reading this Spec.

Architecture

ember g worker <worker-name>

A worker is placed in a pod within /app/workers/. Running the generator produces a Worker and an Interface within the worker pod.

• /app/workers/<worker-name>/interface.js
• /app/workers/<worker-name>/worker.js

A built WorkerApplication will be placed at assets/workers/<worker-name>.js.

Ideally, a worker should be able to use ES imports to include any dependency it needs, but this is tricky as WebWorker's and their relatives do not have access to DOM. Our build tooling should eventually be setup to allow us to include and configure a simple-dom instance ala fastboot on node. At the beginning, it will be on the end user to ensure that what they import will run in a DOMless environment.

WebWorkers can be created via a blob mechanism or via a script url. Our pipeline intends to produce scripts for use via the url method, which means that the build pipeline must produce a standalone script
for each worker in /app/workers/. Additionally, worker.js and interface.js need to remain as modules for use within the application for situations in which the WebWorker API is not available.

Bundling

To create a WorkerApplication, we bundle together interface.js and worker.js along with their dependencies and ember-skyrocket/worker-application, and place the modules in assets/workers/<worker-name>.js. This file must also be responsible for instantiating the worker via some mechanism like the below.

require('ember-skyrocket/worker-application').create({
  name: <worker-name>,
  interface: require('<app-name>/workers/<worker-name>/interface'),
  worker: require('<app-name>/workers/<worker-name>/worker')
});

@runspired @miguelcobain

• install works
• generate a worker works
• can communicate with your webworker in your ember app

Its hard to tell from the readme and other issues whether this plugin actually works?

When I say work, can you spawn a worker in your app, make it do something and report back when complete?

If so, this is amazing.

This chart really makes me sad: http://caniuse.com/#feat=sharedworkers

I think we should still make a stab at using SharedWorkers where supported, but I'm not certain the share is large enough (especially on Mobile) to do much with them yet.

When the Worker API is not present, fall back to the main-thread as efficiently as possible.

We could simply include the worker script onto the main thread and async the calls via a custom backburner queue after afterRender.

We could implement the worker within an iFrame.

We could provide app/workers/<worker-name>/fallback.js ability that has a main-thread optimized version of the workers' tasks.

This task is low priority as workers are widely available IE10+. The primary reason to consider this is for when an API feature is unexpectedly not available within a WebWorker.