> On Thu, Sep 15, 2016 at 8:36 AM, Tim Nevels <timnev...@mac.com> wrote:
> Here’s my perspective on new 4D features. They are great and they can be > useful. Can be useful to you. May be useful to you. But maybe not. .... > So I did a little work and made a demo with this app of how it could work with > multiple windows and showed it to the client hoping to get approval to do the > upgrade work on the app. I just knew they were going to love it. > > They hated it! Thanks for posting this, I've seen it too. Yeah, it's true - what we like often isn't representative of what end users want. Single-window apps are becoming more and more the norm so what you found is only more likely going down the road. > Or do you want to use worker processes just for the sake of using them and the > pure enjoyment of doing it. That can also be a valid reason. :) I'm not that worked up about CALL FORM WINDOW, but I can think of a few places where it would be very nice. Then again, I'm *way* more into headless code than UI work. (I do plenty of UI work, but I like headless code.) Getting CALL WORKER to support a UI? I haven't really thought about it that much...that's not the most obvious case for me. A lot of UI-bound tasks aren't straightforward to parallelize and then there's a lot of threshing/overhead potential in managing the messaging. On the other hand, I'm really, really, really into background tasks. Don't think of CALL WORKER as a subordinate tool for CALL FORM WINDOW. They're totally different, at least in my mind. As I probably said at the top of this thread, I've been writing task queues for about 30 years (!) and can't imagine life without them. So many uses. If you want to scale (really scale), you need distributed processing. If you want to manage distributed processing, you need a task/message-oriented architecture. Does CALL WORKER fit into this? Kind of. Not 100% since it seems to be single-machine oriented, but it's a great first step and, if you set your code up right, you can pretty seamlessly extend it to a multi-machine or multi-language solution based on records (which also adds persistence, if you need it, and traceability when you want it) and/or an external queuing system (IronMQ looks pretty good, I have to say.) A few other notes: * If anyone is thinking about how to use process/IP vars in CALL WORKER, you're thinking about it wrong. Not because you're a bad person, and not primarily for technical reasons. A task should be *atomic* and not bound to the original calling context. Anything else is a huge, snarly, evil box of goo. Filled with rusty razorblades. Forget variables, they're completely unhelpful in this context. Unless you want to stand on a bunch of gooey, rusty razorblades. * Pre-emptive vs. cooperative threads. Is this the new "For loops are faster" of the 4D world? Seriously, most of us and most of our apps absolutely won't know or care. The guys in France that write 4D and 4D Server? Yes, they should care. A lot. Us? Not so much. I'm filing under "worry about it when I've got a reason to". Apart from that, I'll go with the words of Bill Atkinson (he wrote QuickDraw and HyperCard, back in the day): "How do you get a 400% optimization? Stop doing something stupid." So, I'll just try not to do obviously stupid things ;-) * Don't think of messaging as client-server. Think of it as sender and recipient. Then a lot of the confusion/complexity about callbacks looks different. A callback is a return address. The state of the art has changed in the field a lot in the past decades...queuing has gone from being a arcane, back-office/mainframe subject to a core component of the software we use every day. The right or wrong polling strategy can make or break you. This isn't news...but now it's common knowledge. (Long-polling or push instead of constant repolling. Constant repolling is the naive approach...I've used it...it's obvious...I now hand my head in shame. It really does saturate resources way too fast for no reason. I like push everywhere now.) CALL WORKER has a lot of potential and I think will be a gentle introduction to task queues for a lot of 4D developers. They look dead easy to use. Impressively so...way to go 4D. Given their limits (as I understand them), I'll repeat a few recommendations or anyone that thinks that they _might_ move towards a multi-machine or multi-platform system in the future: 1) Ignore process and IP variables. Period. (In fact, I'd recommend this no matter what - mingling variables this way is kind of a crappy way to code anyway.) 2) Make your payload one parameter, and make that JSON. (Real JSON that any language can parse.) 3) If you need larger/more complex data, store it in a record/file/whatever and include a reference in the JSON that enables the worker/task process to load the details. That's it. If you don't ever plan to go beyond the built-in feature set, then I think that point #2 can be ignored. It's pretty sweet that 4D lets you pass raw parameters in - just like with New process. But, it's 4D specific and a bit rigid. I'm planning to try out simple parameters as I get started with 4D's new feature...and then I'll move over to a JSON block instead. But when trying a new feature, it's way easier to take the path of least resistance. Just to know, I tend to write a lot of code to throw away (even whole scratch databases) when learning a new feature. Once you get too much code invested in a strategy, it's hard to toss it out...so I write simple experiments, iterate a few times...figure out what I like and then throw out the experiments. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
