tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/13305-modules-vs-workersRobotlegs: Discussion 2016-05-18T08:52:33Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/391211002016-02-11T17:58:46Z2016-02-11T17:58:46ZModules vs. Workers<div><p>Hello!</p>
<p>Sorry for the late reply.<br>
Interesting topic.</p>
<blockquote>
<p>I have finally gotten a significant portion of the application I
have posted about before working within the Robotlegs framework! It
has definitely made things much easier to manage and the program
overall more robust.</p>
</blockquote>
<p>I'm glad to hear that about your project and also that I'm not
the only one using robotlegs these days ;)</p>
<blockquote>
<p>I am sure workers would be compatible with Robotlegs, I just
have not seen any guides on how to do it. Are workers any different
in practice than modules?</p>
</blockquote>
<p>I'm not very familiar with as3 workers. I've tried them out a
while back when they became available. From what I understand,
robotlegs can't manage the communication with a Worker like it does
with Modules, because it can't detect the creation of a Worker in
another instance of the ActionScript VM, thus it can't create a
child-context and a ModuleConnector for it. robotlegs Modules
communicate via events dispatched on a shared event dispatcher that
the ModuleConnector would create when a new context is initialized.
A Worker is not added to the stage of the main application and as
far as I know it also doesn't have a stage property. Am I
wrong?</p>
<p>Something I wrote about how the robotlegs Modularity extension
works a while ago:</p>
<p><a href="https://github.com/Ondina/robotlegs-bender-as3-modular-example/blob/master/README.md">
https://github.com/Ondina/robotlegs-bender-as3-modular-example/blob...</a></p>
<p>Maybe I'm wrong, but I think there is no out of the box solution
for the communication between robotlegs and as3-workers.<br>
Unfortunately I don't have time for experimenting with as3-workers
at the moment.</p>
<blockquote>
<p>I am thinking that for a couple of operations that are intensive
and time consuming, it would enhance usability to perform them in a
separate worker/module (therefore, another thread, correct?)</p>
</blockquote>
<p>Only workers run concurrently in separate threads.</p>
<p>Here is what you can do until you find a better solution:</p>
<p>Have a class inside of your main context ( the primordial worker
in worker's parlance ) take care of the creation of workers. Let it
communicate with the worker(s) via a MessageChannel or a Mutex or
whatever else. Inside the results handler dispatch a modular event
on the robotlegs shared event dispatcher, so that other classes in
the main context or even other Modules (not workers) can listen to
the event and react accordingly. The class managing the creation of
Workers can also listen to events dispatched from Modules and let
the Worker(s) do whatever is needed or pass some data onto
them.<br>
Of course, the Modules and the main context should have the
modularity extension installed and a ModuleConnector configured
with the needed channels. You can see how it's done in my examples
on github :</p>
<p><a href="https://github.com/Ondina/robotlegs-bender-modular-air">https://github.com/Ondina/robotlegs-bender-modular-air</a><br>
<a href="https://github.com/Ondina/robotlegs-bender-as3-modular-example">https://github.com/Ondina/robotlegs-bender-as3-modular-example</a></p>
<p>If you need more help with the modular extension just post your
questions here.</p>
<p>I'd suggest taking a look at these frameworks / libraries for
inspiration:</p>
<p><a href="https://github.com/doublefx/easyWorker">https://github.com/doublefx/easyWorker</a><br>
<a href="https://github.com/MindScriptAct/mvcEpress-extension-workers">https://github.com/MindScriptAct/mvcEpress-extension-workers</a></p>
<p>Also, you could contact @Deril, the creator of the mvcEpress
framework (inspired by puremvc and robotlegs) He is open-minded, so
I think he won't mind answering a question about
Workers&Robotlegs :)</p>
<p>Paul Robertson (probertson on github) is an experienced
robotlegs user and also, if I remember correctly, the author of the
Worker's documentation on the Adobe sites. Try contacting him as
well.</p>
<p>In any case, if you get an answer or find yourself a solution
please report back, so that other robotlegs users can benefit as
well.</p>
<p>Ondina</p></div>Ondina D.F.tag:robotlegs.tenderapp.com,2009-10-18:Comment/391211002016-02-23T19:27:58Z2016-02-23T19:27:58ZModules vs. Workers<div><p>Thanks Ondina. I see now the differences with modules and
workers. When I first started using Robotlegs, I know I got some
kind of basic worker working. I think I treated it as a service and
the actual worker as something external (like a URLRequest or
RemoteObject). When I do have time to really dive into it I will
post my findings.</p></div>dkartentag:robotlegs.tenderapp.com,2009-10-18:Comment/391211002016-02-29T15:05:17Z2016-02-29T15:05:17ZModules vs. Workers<div><p>You're welcome. It's always a pleasure talking to you :)</p>
<p>Treating workers as services is actually a good idea, especially
when they are supposed to do things like "PDF generation, uploading
files to FTP and other web interfaces, reading/writing data from
networked hardware interfaces". But, since they cannot communicate
directly with robotlegs, you'd need an intermediary, like the class
I mentioned in my previous post. That class could be a Service. A
WorkerService, maybe? The WorkerService could translate framework's
events into worker's events and vice versa.</p>
<p>It's very tempting to build a worker extension/utility for
robotlegs, like the mvcsexpress one, but as I said, due to a
(long-term) lack of time I can't deal with such a project. But, if
you end up creating such an extension or something similar, I'd be
more than willing to try it out ;)</p>
<p>Good luck and I'm looking forward to hearing about your work on
Workers!</p></div>Ondina D.F.