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=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e429176c9adb07b X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-02-25 10:00:50 PST Message-ID: <3E5BAEA3.10702@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: [OT] Best way to isolate a GUI? (The final concensous?) References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 25 Feb 2003 12:57:55 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1046195876 198.96.47.195 (Tue, 25 Feb 2003 12:57:56 EST) NNTP-Posting-Date: Tue, 25 Feb 2003 12:57:56 EST Organization: Bell Sympatico Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Xref: archiver1.google.com comp.lang.ada:34574 Date: 2003-02-25T12:57:55-05:00 List-Id: Robert C. Leif wrote: > Warren W. Gay wrote: > "If more than one task once notice of an event, then you need to allow > for "multicasting" the event (simple with callback lists). > > If you use a protected object, for "multicasting" as is done in > the "Concurrency in Ada" book, then like the message queue, you still > have the "return data" problem. The added problem here is that now > you have a certain amount of new "indeterminism" added to the mix, > because the multicasting may multicast in a different sequence, > according to timing. > > Of course this is fixable, because it can be serialized, but it does > add some complexity, and perhaps some inefficiency as well." > > However, only one procedure can write to the web page. Multiple functions > can read the page. Since an XML web page often contains data, this is an > appropriate mode of protection. I don't understand the point that you making here. I don't have an issue with multicasting per se. I am just suggesting that one must allow for "return data" for use in some events (not all events are one way information transfers). > Since CLAW is an example of the utility of > tagged types for windows, an appropriate combination of a protected and > tagged type (Ada 200Y) could provide a solution based on Ada. Hopefully, > this would either reduce the use of pointers or eliminate their use. I don't understand what any of this has to do with what is being discussed. > Two interesting questions are could an XML paging system be written in SPARK > or employ the Ravenscar profile? Would this increase the security of the > system? > Bob Leif I must be missing something, because I see no connection here. Warren. > -----Original Message----- > From: Warren W. Gay VE3WWG [mailto:ve3wwg@cogeco.ca] > Sent: Monday, February 24, 2003 10:06 AM > To: comp.lang.ada@ada.eu.org > Subject: Re: [OT] Best way to isolate a GUI? (The final concensous?) > > Unfortunately I have to be a bit brief in this reply (shortened > lunch today ;-) > > Marin David Condic wrote: > >>Warren W. Gay VE3WWG wrote in message >>news:3E5669C8.30305@cogeco.ca... >> > > .... > >>>If we were to move to a task centric model, how would the application >>>register (link) a task entry (queue) to a specific widget? It has >>>been a while since I have played with tasking, so is it possible >>>(for example) to gain the address of an entry (queue)? (This is >>>similar to the idea matching Qt's signals with slots, except we've >>>introduced a tasking model). Assuming you can't take the address of >>>a task entry, the only way I can see this working is via a procedure >>>(callback) that then calls the task entry (a layer proc). >>> >> >>I wouldn't try to hook tasks to the events generated by a widget. That's >>just a callback wearing a different suit. I'd create a protocol of > > messages. > >>The app starts up and sends to the GUI whatever initialization is required >>to get the windows defined & displayed. (A big XML file like what GtkAda >>uses to define windows?) The windows and widgets and what have you all > > have > >>some kind of identifier associated with them - a unique ID. One or more >>tasks want to make something happen, they build a message targeted to the >>unique ID of interest and send it to the GUI. The user cliks buttons or >>types text or whatever, the widget concerned packages up a message and > > sends > >>it (with its ID) to the app. The app just has to figure out what to do > > with > >>the messages it gets. >> >>Like I said, the messages to/from the app/GUI might want to be handled by > > a > >>"post office" so that individual tasks can decide what events they want to >>see, but that's just another layer of abstraction on top of the message >>system, so it depends on how complex you want to go. > > > Having given it some thought over the weekend, and after review that > fine book "Concurrency in Ada" (or something like that), I'll just > quickly summarize some of the issues that occurred to me: > > 1. Event queues don't work well, unless you've defined some way of > "returning event data". By this, consider a "verify" widget event, > where you want to provide a callback to perform a user verification > on some text input widget. The verify event must return a VALID > or NOT_VALID response. > > Callbacks perform this easily, because by appropriate use of in/out > arguments, you can plan for returned data. > > For event queue's, the data is "one way". This is not to say that it > is unsolvable, just perhaps "inconvenient". > > 2. A bi-directional "pipe" introduces other problems like latency, > and sequencing (like two pieces of code returning different values). > > 3. If more than one task once notice of an event, then you need to allow > for "multicasting" the event (simple with callback lists). > > If you use a protected object, for "multicasting" as is done in > the "Concurrency in Ada" book, then like the message queue, you still > have the "return data" problem. The added problem here is that now > you have a certain amount of new "indeterminism" added to the mix, > because the multicasting may multicast in a different sequence, > according to timing. > > Of course this is fixable, because it can be serialized, but it does > add some complexity, and perhaps some inefficiency as well. > > >>>One should note however, that "main loop" hangs are still possible >>>if you don't plan your task model correctly. For example if one >>>event takes too long and another comes along before it finishes >>>(because the user is clicking the button again), the rendezvous >>>will block until the task is able to accept another request. >>>To avoid this of course, you could pass off the request to a >>>separate task, but then you'd have to manage the backlog that an >>>impatient user might create by hammering a button repeatedly. >> >>Don't do that and it will stop hurting. :-) > > > Of course, but apply a young kid to a mouse, and let him click > away, and it is amazing how many GUI systems/applications come > crashing to its knees! Yes, I know.. keep kids away from the mouse! > > >>Use messages and decide on what >>to do if you start getting duplicate messages or floods of them. Start >>dropping them on the floor? The user clicks the button 37 times you react > > to > >>it 37 times even if it takes you a while? Handle each widget with its own >>task and buy a really massive multiprocessing computer to handle the >>thousands of tasks it will have? I think as long as you have a message >>protocol, you're free to figure out numerous ways of handling the traffic. > > > Of course, these are all solvable problems. But some of these > problems are easier to solve in some frameworks, rather than > others (at least it must be considered). > > >>>I am having a little trouble picturing how this tasking model >>>can be done, with my limited experience with tasks in Ada. >>>Would you be able to use a entry "family" number to link >>>these together dynamically by use of the number? I'll have >>>to dig out my tasking book tonight. >> >>The task starts, it registers for the events it is interested in (opening >>files, if you will) and then hangs on some kind of "Receive the next >>message" procedure. It quits when it gets the "Shut yourself down" > > message. > >>Everything else is some form of case statement or dispatch based on the >>message received. > > > OK, but this act of "registering for events" is either going to > return a handle to a queue or protected object acting as such. > > But your model considers events as a one way message flow, which is > clean and simple. But it doesn't address the verify callback > scenario, which is but one example of where data needs to be > returned (consider that once a verify has failed, there is no > need to call other verify callbacks for example). > > This is not unsolvable, but it seems rather inconvenient and > open to other problems. > > >>>I am intrigued by this idea.. just trying to picture a practical >>>implementation of it. >> >>Give it some thought. I think that one might be able to evolve some kind > > of > >>low-level wrapper/post-office/client-server thingie that could decouple > > the > >>app from the GUI in a way that might allow multiple GUIs and GUI builders > > to > >>be working at the other end. It might be worth making some kind of attempt >>at a limited prototype to see how it might work in practice.....hmmmmmm >> >>MDC > > > I think it is a worthy goal, but present musings don't seem > all that practical when I consider some of the problems that > come up. Maybe we just need a better model ;-) > > My lunch time is over... I'll have to ponder this more later. > -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg