From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.107.198.12 with SMTP id w12mr11964425iof.105.1521730661168; Thu, 22 Mar 2018 07:57:41 -0700 (PDT) X-Received: by 2002:a9d:3053:: with SMTP id w19-v6mr624355otd.0.1521730660810; Thu, 22 Mar 2018 07:57:40 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!paganini.bofh.team!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u184-v6no848109ita.0!news-out.google.com!d3-v6ni1112itf.0!nntp.google.com!199-v6no846043itl.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 22 Mar 2018 07:57:40 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=47.185.233.194; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.194 References: <9ed9edb1-3342-4644-89e8-9bcf404970ee@googlegroups.com> <26a1fe54-750c-45d7-9006-b6fecaa41176@googlegroups.com> <858fbe8b-43a2-4ee3-ad51-1d100123a1a3@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada-Oriented GUI From: "Dan'l Miller" Injection-Date: Thu, 22 Mar 2018 14:57:41 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:51132 Date: 2018-03-22T07:57:40-07:00 List-Id: On Thursday, March 22, 2018 at 4:12:17 AM UTC-5, Dmitry A. Kazakov wrote: > On 21/03/2018 23:16, Dan'l Miller wrote: > > Dmitry wrote: > >> This is not how asynchronous I/O works in > >> many cases. The I/O request is > >> queued in one thread, initiated in another, > >> processed in third, completed in fourth. > >=20 > > (Other than message-queue-based software architectures,) >=20 > A great number of protocol stacks work this way. Almost all I/O=20 > libraries deploy callbacks on data arrival. >=20 > Some have the design alike to GUI when you are forced to call something= =20 > like Do_IO from a thread and get a callback from within Do_IO. >=20 > But in general nothing in said or required about the contexts of any=20 > calls and callbacks. >=20 > > please name even one async =E2=80=A2=E2=80=A2system call=E2=80=A2=E2=80= =A2 on any OS or OS-framework thereof that requires traversal of those 4 = =E2=80=A2=E2=80=A2app-domain=E2=80=A2=E2=80=A2 threads to produce results (= e.g., filesystem read) asynchronously. >=20 > I don't really know what you mean. Yes, you are correct: you do not understand. > Windows overlapped I/O queues a request from your thread. When I/O is=20 > initiated it can traverse a number of kernel threads (e.g. Deferred=20 > Procedure Call etc). Any number of user-space threads can wait for=20 > associated Windows event objects or poll the overlapped I/O result. You would put app-domain GUI and GUI-facing presentation (e.g., VIPER prese= nter) layers in the kernel? Oh my goodness you are incredibly bad at softw= are architecture. Rx is a technology for within an app-domain UI and UX pr= ocessing, and perhaps the UX-facing interface-fa=C3=A7ade of backend proces= sing. https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38d= e52 VIPER architecture best partitions UI, UX, and back-end processing for an a= pp-domain=E2=80=94none of which is unwisely in the kernel as you would sugg= est. The nonportable peculiar-to-OS/framework portions of the app-domain's= UI (either GUI or ChUI or command-line) go in a VIPER view layer. The por= table generic-among-all-OSes/frameworks portions of the app-domain's UX go = in a VIPER presenter and router layers. VIPER interactor and entities layer= is where all the app-domain backend processing occurs. Rx is intended for= the VIPER view, presenter, and router layers. Rx or Ix overt representati= on of dataflows-of-VIPERentities might find usefulness in some portions of = the interactor layer, but this is a matter of personal taste. Certainly, R= x and Ix (as currently formulated) would never cross into kernel space. Dm= itry, you are so far off in the weeds there. > Anyway, as Randy already said, it is incredibly uncomfortable to build=20 > the whole application around GUI. I agree. That is why VIPER is the best software architecture so far for = app-domains that contain UI/UX (when compared to the MVC and MVVM ilk) beca= use VIPER clearly quarantines UX away from backend processing, and VIPER cl= early quarantines nonportable OS-specific/framework-specific app-domain UI = from portable UX. Dmitry, if you haven't stayed current with VIPER, you re= ally should, because VIPER is embraces your/our school of thought. > The first and foremost requirement for=20 > a decent GUI framework is to let us breath[e]. VIPER's strict quarantining of UX & UI away from all backend processing i= n interactors & entities provides you not only the enormous space to breath= e, but also sharp & fierce software-architectural weapons to push back on t= he UI/UX people to stay within only their quarantined areas, not polluting = the backend processing. That being said, Ix begat Rx historically; Ix originated within backend pro= cessing (what VIPER calls interactors) of data (what VIPER calls entities, = as a hat tip to thin OO representation of each record). Then someone notic= ed that Ix's pull-based semantics could be reversed as push-based semantics= to be repurposed to event-driven UI/UX. Even in backend app-domain proces= sing (in user-space, not kernel-space, as you suggest), there is a natural = progression to move away from thinking about verb-centric actions (i.e., 19= 70s structured programming) to verbs-subjugated-to-noun-centric encapsulati= on (i.e., 1980s/1990s OO) to rivers of nouns/data/entities channelized into= verb processing (i.e., Rx and Ix in the 2010s). Rx is not unlike wire-spe= ed processing of packets in modern network processors: focus on the channe= lized dataflow as a river flowing by, picking out a filtered datum as it fl= ows by to operate on it under realtime deadlines to keep up with the flowra= te of the river. It is merely the natural progression of the Zeitgeist, wh= ose societal exhaled-breath wind has been blowing in this direction for aro= und 50 years now.