Re: Ada-Oriented GUI

["Dan'l Miller" <optikos@verizon.net>]

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.
> > 
> > (Other than message-queue-based software architectures,)
> 
> A great number of protocol stacks work this way. Almost all I/O 
> libraries deploy callbacks on data arrival.
> 
> Some have the design alike to GUI when you are forced to call something 
> like Do_IO from a thread and get a callback from within Do_IO.
> 
> But in general nothing in said or required about the contexts of any 
> calls and callbacks.
> 
> > please name even one async ••system call•• on any OS or OS-framework thereof that requires traversal of those 4 ••app-domain•• threads to produce results (e.g., filesystem read) asynchronously.
> 
> 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 
> initiated it can traverse a number of kernel threads (e.g. Deferred 
> Procedure Call etc). Any number of user-space threads can wait for 
> associated Windows event objects or poll the overlapped I/O result.

You would put app-domain GUI and GUI-facing presentation (e.g., VIPER presenter) layers in the kernel?  Oh my goodness you are incredibly bad at software architecture.  Rx is a technology for within an app-domain UI and UX processing, and perhaps the UX-facing interface-façade of backend processing.

https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52

VIPER architecture best partitions UI, UX, and back-end processing for an app-domain—none of which is unwisely in the kernel as you would suggest.  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 portable 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 representation of dataflows-of-VIPERentities might find usefulness in some portions of the interactor layer, but this is a matter of personal taste.  Certainly, Rx and Ix (as currently formulated) would never cross into kernel space.  Dmitry, you are so far off in the weeds there.

> Anyway, as Randy already said, it is incredibly uncomfortable to build 
> 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) because VIPER clearly quarantines UX away from backend processing, and VIPER clearly quarantines nonportable OS-specific/framework-specific app-domain UI from portable UX.  Dmitry, if you haven't stayed current with VIPER, you really should, because VIPER is embraces your/our school of thought.

> The first and foremost requirement for 
> a decent GUI framework is to let us breath[e].

  VIPER's strict quarantining of UX & UI away from all backend processing in interactors & entities provides you not only the enormous space to breathe, but also sharp & fierce software-architectural weapons to push back on the 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 processing (what VIPER calls interactors) of data (what VIPER calls entities, as a hat tip to thin OO representation of each record).  Then someone noticed 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 processing (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., 1970s structured programming) to verbs-subjugated-to-noun-centric encapsulation (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-speed processing of packets in modern network processors:  focus on the channelized dataflow as a river flowing by, picking out a filtered datum as it flows by to operate on it under realtime deadlines to keep up with the flowrate of the river.  It is merely the natural progression of the Zeitgeist, whose societal exhaled-breath wind has been blowing in this direction for around 50 years now.