From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9566 invoked by alias); 19 Nov 2003 17:09:30 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 9555 invoked from network); 19 Nov 2003 17:09:28 -0000 Received: from unknown (HELO garm.central.cmich.local) (141.209.15.48) by sources.redhat.com with SMTP; 19 Nov 2003 17:09:28 -0000 Received: from leon.phy.cmich.edu ([141.209.165.20]) by egate1.central.cmich.local with Microsoft SMTPSVC(5.0.2195.6713); Wed, 19 Nov 2003 12:08:43 -0500 Received: from localhost (unknown [127.0.0.1]) by leon.phy.cmich.edu (Postfix) with ESMTP id 9947C7001D; Wed, 19 Nov 2003 12:08:42 -0500 (EST) Date: Wed, 19 Nov 2003 17:25:00 -0000 From: Eric McDonald To: bboett@adlp.org Cc: xconq7@sources.redhat.com Subject: Re: UI proposal In-Reply-To: <20031119151651.GK387@adlp.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Nov 2003 17:08:43.0848 (UTC) FILETIME=[C9768480:01C3AEBF] X-SW-Source: 2003/txt/msg00795.txt.bz2 Hi Bruno, On Wed, 19 Nov 2003, Bruno Boettcher wrote: > but i thought that adding other interfaces was hard due to the deep > interwindling of xconq game machine and UI, the stuff that prevented a > clean client server design IIRC? I am no authority on adding interfaces to Xconq as I haven't spent much time with the UI code, but the kernel is essentially abstracted from the interfaces. I also believe that Stan(?) pointed this out recently, and he said that the ability to add new interfaces was the primary motivator for this. From a kernel hacker's perspective, I can tell you that I don't see alot of evidence of deep intertwining. However, I will agree that a client-server model would be nice. I currently don't feel ambitious enough to attempt the separation, and dropping in the clisrv communication layer in between. I don't plan on doing this in the 7.6 release cycle either. But perhaps others are more ambitious.... The reason I have thought about a clisrv architecture in the past was not for the GUI's, but for the AI's. Regards, Eric