> Interesting approach - thank you for posting that. DvR: You, of all people, will *love* this approach.
> Lacking "callers" and C_Object, I've been using On outside call + > ObjectTools + IP messaging based on the ITK message queuing system. Once you have access to V16, you may find: * You like C_OBJECT because it's very fast and native. But it won't do everything that ObjectTools does. * You may still want to use IPC channels from NTK. They're traditional messages, easily support a wider range of messaging patterns, and can be used to-from anywhere. * CALL FORM/CALL WORKER are great! You'll love them. On Outside Call was always documented as being unreliable while CALL FORM / CALL WORKER guarantee delivery. (Unless you kill a worker, kill a process, kill 4D, or crash. But, hey, that's pretty reasonable for a lot of situations.) > I'm not sure if this is germane to Call form/worker but I include a "reply to ID" > in the message that's sent. Yes, that can be entirely relevant. These 'calls' aren't a channel, you're tossing blocks of code at the end of the thread of control over there for one-off execution. There is no return message. You can send along callback details if, for example, you need a result. There are times when you'll find NTK's IPC channels easier. And, yes, message discipline is _super_ beneficial. You mention that you're doing message routine. This can be pretty darn impossible to trace or debug if there's nothing in the message about the path that it has followed. Tip: I've found it helpful to define a 'recipient' object as a specific type. This can be the recipient of a CALL FORM/CALL WORKER message or the callback details when you want a result, error, or confirmation message returned. By treating this as a custom data type, it's easy to have a single method for creating recipients and for validating them. "Validating" matters if you, for example, want to be sure that method names exist and that window refs are valid. > My projects are just moving to 15.x now so Call worker/call form are still > a bit out of reach for me but I'm glad to see that these have been added to > the language. They're a natural outgrowth of OOC, Call subform container, > etc., and we *finally* have a way to communicate with those windows opened > in the asterisk. Yeah, you'll love it. Given our existing framework, you'll feel like some things are missing - so keep NTK around. Also, vote for a native WebSockets implementation. This would be an *amazingly* great addition to 4D. You could have a persistent, bi-directional, point-to-point pipe between processes on one machine or different machines. Game changer. WebSocket protocol on 4D webserver http://forums.4d.fr/Post/EN/19129127/1/19129128 ********************************************************************** 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:[email protected] **********************************************************************
