David: Just read the feature request thread for WebSockets and I'm pretty certain I voted for it (clicked 4 stars on the first message in the thread).
WebSocket fits well into the concepts of Call worker/form in that it's providing developers with more granular connections and, hence more granular control, over how data is requested and supplied. That would be a very welcome addition to the 4D toolset. -- Douglas von Roeder 949-336-2902 On Fri, Mar 17, 2017 at 3:02 PM, Douglas von Roeder <[email protected]> wrote: > David: > > I'll read up on the web sockets - when I first saw that I misread it for > "WebObjects". A cold chill ensued. > > C_Object is a great addition to the language. Agree that it doesn't do > everything that OT does but that why we have wrapper routines. I've > extended Cannon's OBJ_Module with OBJ_SetArray_Text/Long/Real and a few > other array commands and I can get a lot done with C_Object that I'm doing > in OT. The biggest benefits - scope/garbage collection and the content of a > C_Object is visible in the debugger. Those are "bloody mavhelous". > > "you're tossing blocks of code at the end of the thread of control over > there for one-off execution." > Excellent way to phrase it. And the emphasis is on "over there" because > the code executes in the context of the destination form. > > "execute in form" similar to "execute on client" > > "On Outside Call was always documented as being unreliable while CALL > FORM / CALL WORKER guarantee delivery." > OOC worked well form me, as far as I know (emphasis on the "AFAIK"). > I did have to tweak my original code to work in a Repeat loop, as you say, > Call form/Call worker will always get through so there's no need to jump > through hoops (loops) to make sure the message arrived. > > > "NTK's IPC channels easier" - agreed. I"m using an array-based derivative > of that approach (taken from ITK about 20 years ago) with a change in > 2000-01 and that's it. Highly reliable and zero maintenance but it doesn't > allow me to get to a specific form…which is what's needed to get at the * > dialog. Very nice to have multiple active windows in a process but > disappointing that I couldn't get to it with a message. > > > "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." > I only had to chase messages "down a rabbit hole" a few times over the > years. Two ways of reducing the odds of that happening - one of the > properties of a message will allow the message and its metadata to be > displayed added to arrays displayed in a grid. I needed that to debug some > code that had become very involved and the end result is that it helped > force me to rethink my approach. > > The other technique that I've used it a bit dated now but was very helpful > before V11, back in the dark ages when "Find in design" was dreadfully > slow. That situation convinced me to use IP vars in the message. From > *MSGIP_Vars_Init*: > > C_TEXT(<>MSG_InsertCarriageReturn) > <>MSG_InsertCarriageReturn:="<>MSG_InsertCarriageReturn" > > C_TEXT(<>MSG_ProposalIsLocked) > <>MSG_ProposalIsLocked:="Proposals_is_Locked" > > C_TEXT(<>MSG_BringToFront) > <>MSG_BringToFront:="<>MSG_BringToFront" > > C_TEXT(<>MSG_Close) > <>MSG_Close:="<>MSG_Close" > > C_TEXT(<>PROC_Activated) > <>PROC_Activated:="<>PROC_Activated" > > > From On Outside call: > Repeat > > C_LONGINT($msgHandle_L) > $msgHandle_L:=MSGIP_Message_Get (Current process) > > C_TEXT($msg_T) > $msg_T:=MSGIP_TextMessage_Get ($msgHandle_L;False) > > Case of > : ($msg_T=<>MSG_BringToFront) > PROC_ResumeAndBringToFront (Current process) > > : ($msg_T=<>MSG_Close) > CANCEL > End case > > MSGIP_Message_Clear ($msgHandle_L) > > Until (MSGIP_MessageCount_Get (Current process)=0) > > > To your point about the provenance of the message, another significant > argument for an object without which it would be gruesome to try to add > that sort of data to…a BLOB?! No interest in the level of mental gymnastics… > > Time to have a looksee here - http://forums.4d.fr/Post/EN/ > 19129127/1/19129128 > > > -- > Douglas von Roeder > 949-336-2902 <(949)%20336-2902> > > On Fri, Mar 17, 2017 at 2:18 PM, David Adams via 4D_Tech < > [email protected]> wrote: > >> > 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] >> ********************************************************************** >> > > ********************************************************************** 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] **********************************************************************
