Modules vs. Workers
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. I do have some more questions now that I am much more familiar with the Robotlegs way of doing things, this one is on the modular capabilities of Robotlegs. In the past, we employed ActionScript Workers to enhance performance and speed for operations like uploading to an FTP host, or importing a parsed file into a SQLite database. 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?
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?) Examples include PDF generation, uploading files to FTP and other web interfaces, reading/writing data from networked hardware interfaces.
Comments are currently closed for this discussion. You can start a new one.
|?||Show this help|
|ESC||Blurs the current field|
|r||Focus the comment reply box|
|^ + ↩||Submit the comment|
You can use
Command ⌘ instead of
Control ^ on Mac
Support Staff 1 Posted by Ondina D.F. on 11 Feb, 2016 05:58 PM
Sorry for the late reply.
I'm glad to hear that about your project and also that I'm not the only one using robotlegs these days ;)
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?
Something I wrote about how the robotlegs Modularity extension works a while ago:
Maybe I'm wrong, but I think there is no out of the box solution for the communication between robotlegs and as3-workers.
Unfortunately I don't have time for experimenting with as3-workers at the moment.
Only workers run concurrently in separate threads.
Here is what you can do until you find a better solution:
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.
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 :
If you need more help with the modular extension just post your questions here.
I'd suggest taking a look at these frameworks / libraries for inspiration:
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 :)
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.
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.
2 Posted by dkarten on 23 Feb, 2016 07:27 PM
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.
Support Staff 3 Posted by Ondina D.F. on 29 Feb, 2016 03:05 PM
You're welcome. It's always a pleasure talking to you :)
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.
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 ;)
Good luck and I'm looking forward to hearing about your work on Workers!
Ondina D.F. closed this discussion on 12 May, 2016 12:07 PM.