From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8328 invoked by alias); 30 Aug 2011 08:19:35 -0000 Received: (qmail 8305 invoked by uid 22791); 30 Aug 2011 08:19:29 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-da01.nokia.com) (147.243.128.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 30 Aug 2011 08:19:10 +0000 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p7U8J86p014000 for ; Tue, 30 Aug 2011 11:19:08 +0300 From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= To: gdb-patches@sourceware.org Subject: Re: [RFA] 12843 Date: Tue, 30 Aug 2011 08:19:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; i686; ; ) References: <4E56C5A0.60802@redhat.com> <201108291417.02082.andre.poenitz@nokia.com> <20110829192112.GA29862@host1.jankratochvil.net> In-Reply-To: <20110829192112.GA29862@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201108301021.15313.andre.poenitz@nokia.com> X-Nokia-AV: Clean X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-08/txt/msg00586.txt.bz2 On Monday 29 August 2011 21:21:12 ext Jan Kratochvil wrote: > On Mon, 29 Aug 2011 14:17:02 +0200, Andr=C3=A9 P=C3=B6nitz wrote: > > I am really interested in the IDE case which I believe to be one intent= ed > > use case for the MI protocol, and would like to ask to consider choosin= g=20 > > a robust protocol that makes general automated interaction with gdb sim= ple. >=20 > When you are already considering changes on the front end side has been > discussed some replacement by D-Bus, ORBit2 or similar RPC protocol? Please, pretty please, don't go down that road. Consider using something that's available _painlessly_ cross-platform, possibly avoid additional dependencies just for transfering a few bytes. A text protocol with well-defined escape rules is completely=20 fine here, and not _that_ difficult to define and implement. It's already today quite some effort to get a properly Python-enabled gdb up and running and distributed on e.g. Windows. There wasn't even an "official" build for quite some time... > It would make all the parsing and escaping not any issue. It looks like the "parsing and escaping problems" come from the attempt to stay compatible with the currently existing linespec=20 syntax. There seemed to be consensus that a second set of parameters with well-defined syntax would solve that problem. > I spend these days on some entryval extensions of MI protocol=20 > so I have these ideas. I've been adding extra "MI style" output fields for all kind of data, including structured and image data, for two years now, and=20=20 escaping is _really_ not a problem. At worst, and if it needs to be fast, one can base64- or hex-encode on one side and decode on the other. It's a _M_achine _I_nterface after all. Andre'