Re: [OT] Best way to isolate a GUI? (The final concensous?)

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

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 <ve3wwg@cogeco.ca> 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