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=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI autolearn=unavailable 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-24 17:22:10 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!nycmny1-snf1.gtei.net!news.gtei.net!colt.net!mango.news.easynet.net!easynet-quince!easynet.net!teaser.fr!enst.fr!not-for-mail From: "Robert C. Leif" Newsgroups: comp.lang.ada Subject: RE: [OT] Best way to isolate a GUI? (The final concensous?) Date: Mon, 24 Feb 2003 17:20:10 -0800 Organization: ENST, France Message-ID: Reply-To: "comp.lang.ada mail to news gateway" NNTP-Posting-Host: marvin.enst.fr Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: avanie.enst.fr 1046136068 48871 137.194.161.2 (25 Feb 2003 01:21:08 GMT) X-Complaints-To: usenet@enst.fr NNTP-Posting-Date: Tue, 25 Feb 2003 01:21:08 +0000 (UTC) To: "'comp.lang.ada mail to news gateway'" Return-Path: X-Envelope-From: rleif@rleif.com X-Envelope-To: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal In-Reply-To: <3E5A5F1C.9040907@cogeco.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-BeenThere: comp.lang.ada@ada.eu.org X-Mailman-Version: 2.1 Precedence: list List-Id: comp.lang.ada mail to news gateway List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Xref: archiver1.google.com comp.lang.ada:34543 Date: 2003-02-24T17:20:10-08:00 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. 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.=20 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 -----Original Message----- From: Warren W. Gay VE3WWG [mailto:ve3wwg@cogeco.ca]=20 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... >=20 ... >>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). >> >=20 > 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. >=20 > 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. >=20 > Don't do that and it will stop hurting. :-)=20 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. >=20 > 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. >=20 > 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 >=20 > 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. --=20 Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg