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 09:38:19 PST Message-ID: <3E5BA8D5.7050403@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 fronteer?) References: <3E511C15.1040404@acm.org> <3E5121BD.4010200@cogeco.ca> <3E51A55A.3000101@cogeco.ca> <3E52A1BF.1020809@cogeco.ca> <3E53CE60.1030008@cogeco.ca> <3E55501D.9050006@cogeco.ca> <3E5669C8.30305@cogeco.ca> <3E5A5F1C.9040907@cogeco.ca> <7vptpg1o58.fsf@vlinux.voxelvision.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 25 Feb 2003 12:33:09 -0500 NNTP-Posting-Host: 198.96.47.195 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1046194390 198.96.47.195 (Tue, 25 Feb 2003 12:33:10 EST) NNTP-Posting-Date: Tue, 25 Feb 2003 12:33:10 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:34572 Date: 2003-02-25T12:33:09-05:00 List-Id: Ole-Hjalmar Kristensen wrote: > "Marin David Condic" writes: > > > >>In my little imaginary world of dreaming up a way to separate the GUI from >>the app, I tend to like a messaging scheme because it is loosely coupled and >>flexible enough that it could probably be mated to a number of GUIs and GUI >>builders as well as staying language neutral. I think if one went another > > > That's one of the reasons the interface to the X window system server is actually > defined as a network protocol. Note however, that these messages have serial numbers for serialization and error checking purposes. However, if you check most X Window programs, error checking is effectively non-existant. The reason for this is that the status coming back, comes much later than the request (the application normally allows new requests to be issued before the status comes back). While errors can be checked and reacted to well after the fact, it becomes rather impractical in most applications. The problem is that once an error is detected, you have to consider what other operations have just been requested, how many of them succeeded, and how many are still on their way to the server. To avoid this, you can have the X Window system work in a synchronous type of mode (I forget the name of this call that controls this), but the performance is so bad that most apps have this off by default, or turn it off when required. So when one considers a design, you must always look at all sides of it, because there are many practical considerations getting in the way of the "ideal", unfortunately. >>route - that involving callbacks - one would likely lose the flexibility and >>find it difficult to make it line up with more than one GUI at a time. While >>callbacks are going to have certain advantages (forcing a certain amount of >>command/response protocol and returning results to the GUI) I think that >>careful design of a messaging system might be able to live without those >>advantages or synthesize them in some other way. So you pays your money and >>you takes your pick. :-) I agree that one should always be questioning the "accepted world" in technical terms (in this case callbacks). Only by doing this are new techniques or discoveries made. However, on this one, I don't think we're quite there yet ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg