From: "André Pönitz" <andre.poenitz@nokia.com>
To: gdb-patches@sourceware.org
Subject: Re: [RFA] 12843
Date: Tue, 30 Aug 2011 08:19:00 -0000 [thread overview]
Message-ID: <201108301021.15313.andre.poenitz@nokia.com> (raw)
In-Reply-To: <20110829192112.GA29862@host1.jankratochvil.net>
On Monday 29 August 2011 21:21:12 ext Jan Kratochvil wrote:
> On Mon, 29 Aug 2011 14:17:02 +0200, André Pönitz wrote:
> > I am really interested in the IDE case which I believe to be one intented
> > use case for the MI protocol, and would like to ask to consider choosing
> > a robust protocol that makes general automated interaction with gdb simple.
>
> 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
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
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
> 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
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'
next prev parent reply other threads:[~2011-08-30 8:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-25 21:59 Keith Seitz
2011-08-26 18:23 ` Tom Tromey
2011-08-26 18:46 ` Keith Seitz
2011-08-26 19:07 ` Tom Tromey
2011-08-27 8:45 ` Eli Zaretskii
2011-08-27 13:17 ` asmwarrior
2011-08-29 19:18 ` Tom Tromey
2011-08-29 7:19 ` André Pönitz
2011-08-29 10:13 ` Pedro Alves
2011-08-29 12:06 ` Matt Rice
2011-08-29 12:15 ` André Pönitz
2011-08-29 13:53 ` Pedro Alves
2011-08-29 19:21 ` Jan Kratochvil
2011-08-30 8:19 ` André Pönitz [this message]
2011-08-30 9:21 ` Jan Kratochvil
2011-08-30 15:02 ` Tom Tromey
2011-08-30 16:34 ` André Pönitz
2011-08-30 17:21 ` Tom Tromey
2011-08-31 8:54 ` André Pönitz
2011-08-29 19:46 ` Tom Tromey
2011-08-29 21:13 ` Keith Seitz
2011-08-30 2:35 ` Daniel Jacobowitz
2011-08-30 15:00 ` Tom Tromey
2011-08-30 17:24 ` Tom Tromey
2011-08-31 18:17 ` Keith Seitz
2011-08-31 18:23 ` Jan Kratochvil
2011-08-31 18:52 ` Tom Tromey
2011-09-02 16:04 ` asmwarrior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201108301021.15313.andre.poenitz@nokia.com \
--to=andre.poenitz@nokia.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox