primarily 1 - creating relational ties between record sources (drag n drop) ex: associate samples with an experiment, drag sample(s) from 1 list form to an experiment entry form 2 - displaying related data in it's own window (communication is one way and short lived), when 'drilling down' does, or is likely to cause issues with circular paths. ex: An Experiment can one or more samples, each sample can be part of multiple experiments solution - on double click display samples in separate process 3 - Sequence value generation. 4 - moving Files from client to server, or server to client 5 - queries on the current table.
I use different methodologies in different places. #1 & #2 - drag n drop & displaying related data - I use IP sets. populate in current process, check in destination process, use if not empty and clear. #3 - Sequence generation - a message queue (arrays) which is 2 way communication #4 - combination of message queue and records. Many instances where users can 'attach' a file to a record are inside transactions, as such I do not want to move the file(s) until the transaction completes (avoids orphaned files on the server). A file is loaded into a blob in a record and saved. When the transaction completes, a message is sent to a server-side process to extract the file from the blob and save it to a pre specified directory structure; upon completion the parent record(s) to which the files were attached are updated with a status. #5 - at times it is necessary to do a query against the table in which the user is currently working, AND the simple results available from SET QUERY DESTINATION are not sufficient. The method(s) used here are generally instance specific. On Fri, 3 Feb 2017 18:08:29 +1100, David Adams wrote: > CALL WORKER and CALL FORM have inspired me to move from V13 to V16. I've > done a lot with queues and messaging down the years and so far really like > what I see about what V16 has to offer. > > But I'm curious - what are other people using inter-process communications > for now? I'm more interested in the problems your solving than the > communications architecture, but any answer is fine. I've used message > queues and IP communications largely for: > > * Moving tasks to underused machines. > > * Running maintenance tasks (integrity checks, etc.) without bothering > users. > > * Providing access to a resource tied to one machine. (External software > with one license, machine with special network access rights, machine > connected to a specific serial device, etc.) > > * Kind of a case of the previous, but consolidating access to a > high-contention resource. For example, a log file. You don't want lots of > processes fighting to get a write lock on a log file. No. Instead, you keep > it open in one process and send that process messages. The process then > pushes the message out to the log. Zillions of times faster, way easier. > That's what Web servers do. > > Pretty much server and background task oriented, not so much UI-oriented. > Because CALL PROCESS/Outside call don't work. Because I like > server-oriented code. Anyway, that's the past. What do other people use > inter-process communications for? > > Okay, can't help myself, here are the main approaches I've seen pre-V16 to > implement such things: > > * IP vars/arrays/semaphores (or not) to create a shared-access queue. > > * Records to push tasks around. (Something I've done a lot of.) > > * IPC channels with NTK. > > * Custom TCP messaging coding using ITK/NTK/4DIC. > > * Messaging over HTTP, be that REST/JSON/SOAP/custom. > > * Messaging over the network using some kind of external HTTP-based server > or Amazon service. > > There are other options in the wider world, but I haven't run into them > being used in a 4D project in the wild. > > Thoughts and examples very welcome. > ********************************************************************** > 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] **********************************************************************
