It is a big description, and the intended ascii formatting kind of made it worse. Unfortunately, I've been sidelined by other work for the last two weeks, but I have the proposal finally fully transferred to a wave. I *think* this link should get you there:
https://wave.google.com/wave/#restored:wave:googlewave.com!w%252BWqHsByV5A If someone could check if that link actually works and that adding the GWT contributors group was sufficient, and then ping me either in the wave water cooler or here, I would really appreciate it. The module does currently work well without patching GWT, but there are also some glaring inefficiencies. In the hope of getting some drive-by responses, I'll pull together a short list of questions and possible changes that could help simplify the process. Thanks, Brendan On Apr 12, 7:49 am, Joel Webber <[email protected]> wrote: > Brendan, > > At a quick glance, this looks pretty much like I would have expected a good > workers library to look like. Is there any way I *could* convince you to > make a wave of it? It's a pretty big description, and would probably diverge > badly on a mailing list (@everyone: If anyone who frequents this list > doesn't yet have a wave account, don't hesitate to ping me so I can get you > invites). > > If I understand correctly, it looks like you've made this work without > patching GWT proper. Assuming that's correct, are there any changes that > would have made it simpler or more efficient? > > Cheers, > joel. > > > > On Thu, Apr 8, 2010 at 9:41 PM, Brendan Kenny <[email protected]> wrote: > > Gah, well, it should have been a wave. > > > Aside from the assorted grammatical problems, the library is > >https://code.google.com/p/gwt-ns/ > > and the all important goal of "To patching of GWT" should of course be > > "NO patching." > > > Also, I'm not sure if the workflow of the current implementation is > > entirely clear. > > > 1) A class extends the WorkerEntryPoint and does what it needs to do, > > dealing with messages from its parent as they arrive. If it fulfills > > the requirements listed above under "Valid Worker Modules," it can be > > instantiated and used as a web worker. > > 2) The parent project instantiates a worker from a worker module as > > listed under "To Use a Worker." The object created can only give > > messages, receive them, and be terminated. > > 3) Developers compile *only* the parent project. The invoked generator > > and linkers handle the rest. > > > On Apr 8, 8:05 pm, Brendan Kenny <[email protected]> wrote: > > > This might be a bit unusual. I have a fairly reasonable proposal for > > > supporting web workers in GWT proper, and a working proof of concept > > > that shouldn't come anywhere near the core toolkit. Everyone seems > > > busy with what looks like 2.1 and the upcoming I/O, so I'm not > > > expecting miracles, but I would appreciate any wider perspective and > > > maybe some Compiler insight to make the implementation less of a > > > complete hack. > > > > A few months ago I put together a module to get workers working nicely > > > with the GWT compiling/linking process. It was originally just on a > > > bit of a lark, but it's proven so easy to use (thanks to GWT, not me) > > > that I've ended up developing a few projects with it, two examples of > > > which I've posted over with the code (http://code.google.com/p/gwt- > > > ns/). I finally have some time to come back to the module and finish > > > some lingering issues, but thought I might try and get some other > > > perspectives first. If there's a GWT 2.1 web worker skunkworks project > > > already in progress, please let me know now =) > > > > To give credit where its due: several files came from the Speedtracer > > > worker overlay code and one or two files came from GALGWT. I've > > > preserved copyright notices everywhere, and everything else is also > > > Apache 2.0 licensed. I also finally got around to watching 2008's GWT > > > Extreme! and found out my compilation scheme is very similar to what > > > Ray Cromwell was up to two years ago (which probably happens a lot). > > > He called it the Generator+Linker+Generator+Linker pattern, though in > > > this case it's more Generator+Linker(+Generator+Linker)*. > > > > Anyway, like Ray Ryan, I wish this were a wave, but I'll stick to the > > > board for now. I tried to keep it short, but it got rather long, so if > > > there is interest I can make it look a bit more like an actual design > > > document in a wave and hook it up to the water cooler. > > > > === Motivation === > > > Web workers, as currently specifiedhttp:// > >www.whatwg.org/specs/web-workers/current-work/ > > > have two primary requirements. They are separate Javascript files, > > > loaded in a worker constructor that > > > 1. Doesn't access the DOM > > > 2. Don't share state or context with other execution contexts (e.g. > > > their parent script). > > > Once a worker is loaded and running, the worker and its parent can > > > pass messages to each other, usually in JSON form. > > > > At least for transitional worker support, I'm suggesting a third > > > condition > > > 3. No single code execution will throw a slow script warning, even > > > when run *normally* in an older/slower browser. > > > This does necessarily limit functionality, e.g. ruling out the usual > > > worker examples of blocking I/O and long running calculations. The > > > first isn't really welcome in the GWT world, anyways, and really any > > > synchronous operation is a bad fit for GWT/Javascript. This condition > > > can also just be considered transitional; I'll go with it for now and > > > just assert that another level of deferred binding could give allow > > > more flexibility on this point. > > > > Accepting these three conditions, a true worker object becomes > > > functionally equivalent to a simple isolated object with only post and > > > receive message methods in its exposed interface (an Actor, if you're > > > into that sort of thing). In practice, the only difference is that > > > some newer platforms will execute the native worker off the main > > > thread. > > > > In exchange for some loss of flexibility, instead of compiling the > > > workers separately, permutations for non-worker-supporting browsers > > > can load the worker code into an asynchronous wrapper (I'm calling it > > > a proxy, but I'm sure there's a more descriptive pattern name out > > > there) and run it on the main thread. This gets you > > > -- a single code base, regardless of browser worker support > > > -- Full development mode support, for the parent and worker scripts, > > > without any OOPHM alterations. The generator just loads the non-worker > > > version of the worker object, regardless of browser. > > > > === Goals === > > > -- Enable the compilation of a GWT worker module to a valid worker > > > script (per current specification). > > > -- Allow any GWT module to instantiate worker modules as a worker > > > object, regardless of target platform's support for native javascript > > > workers > > > -- This includes allowing workers to themselves instantiate sub- > > > workers, including from their own module (per spec). > > > -- Absolutely minimal overhead to ensure gain from use of workers > > > -- Ensure the same behavior from emulated workers as from native > > > workers > > > -- Enable normal development-mode debugging of workers and parent > > > program as they execute. > > > -- Simplest possible construction of worker objects. If a worker > > > module is on the classpath, the module name is enough information to > > > create the worker object, since no state or context will be shared > > > except what is explicitly passed in a message string. > > > -- Creating a native worker should result in only a single server > > > request. > > > -- Worker script files should be aggressively cacheable. > > > -- Adding workers to a project should be as transparent as adding any > > > other module to the build process (excepting logged information and > > > extended compilation time) > > > -- Adding workers should not alter the behavior of any other Linkers > > > defined in a project (most importantly the std, sso, and xs primary > > > linkers) > > > > === Potential Future Goals === > > > -- Different entry points for emulated and native workers. > > > -- The option to have the generator compile a worker module (or > > > specify an already compiled script) for development mode to debug > > > behavior (but not Java source) of native worker. > > > -- Built-in IPC to allow GWT compiler to better do its magic > > > > === Current Implementation === > > > **Implementation goals** > > > -- As stated, no change for other linkers. > > > -- To patching of GWT. (this necessitated some workarounds) > > > > **Valid Worker Modules** > > > Implicit requirements to compile a module as a worker (currently > > > unchecked) > > > -- No DOM access > > > -- No shared state or context with other execution contexts. > > > -- No SSW-generating code > > > > Explicit requirements to compile a module as a worker (currently > > > enforced) > > > -- Addition of a primary linker which packages the resulting script in > > > a simple bootstrapping closure > > > -- A single specified entry point which extends WorkerEntryPoint and > > > implements the required methods > > > -- Properties set such that only one permutation is produced > > > -- No code splitting. > > > The last three aren't set in stone. For instance, multiple > > > permutations might be needed for i18n reasons. Support is certainly > > > possible, but makes the script selection process more complicated than > > > the one described below. By contrast, code splitting seems a little > > > strange in a worker context, but importScripts() is practically built > > > in support for it. > > > > **To Use a Worker Module** > > > Currently, the canonical name of a valid Worker module is all the > > > information needed. Example usage: > > > @WorkerModuleDef("pkg1.pkg2.ModuleName") > > > interface MyWorkerFactory extends WorkerFactory { } > > > MyWorkerFactory factory = GWT.create(MyWorkerFactory.class); > > > ... > > > Worker myWorker = factory.createAndStart(); > > > > An already running worker object is returned. Messages can be passed > > > to the worker via postMessage(), handlers can be attached to listen > > > for messages and errors from the worker, and the worker can be stopped > > > at any time by calling terminate(). > > > > **Non-native Implementation** > > > For platforms without worker support, the Generator creates a new > > > instance of the module's specified entry point and wraps it (as > > > described above). The wrapper is returned. Messages passed into and > > > coming out of the wrapper are queued to decouple worker and parent > > > execution contexts. > > > > **Development Mode/Debugging** > > > Worker emulation that is "close enough" to a native implementation can > > > be used in its place. This means that the main script and all workers > > > are run in (fast) java-land and can be debugged there. This is > > > currently accomplished by development mode always triggering emulated > > > support, regardless of... > > read more » -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
