Re: MI async status output

[Bob Rossi <bob at brasko dot net>]

On Fri, Apr 18, 2014 at 08:42:33PM +0400, Vladimir Prus wrote:
> On 18.04.2014 20:30, Bob Rossi wrote:
> >>Though quite possibly, MI3 should just accept and produce JSON.
> >I think it would be good to have an honest discussion on this topic.
> >
> >It was really easy to write CGDB based on GDB annotations. The obvious
> >problem was that the annotations interface provides very little
> >information. So CGDB is very limited.
> >
> >In steps GDB/MI.
> >   - The GDB/MI grammar is wrong (fix it and you hit the semantic issues)
> >   - When GDB changes, how do the front ends handle the before and after?
> >     Problem: A 1 (GDB) to many (front end) relationship exists making it
> >     difficult to change or improve GDB.
> >   - How do front ends work with different versions of GDB?
> >     Problem: A 1 (front end) to many (GDB versions) relationship exists
> >     making it difficult for a front end to work well with any version of
> >     GDB. Front ends naturally suffer from a least common demoninator
> >     feature set. That is, only use the features available in most
> >     versions of GDB.
> >
> >The solution to these problems is pretty clear, lets give developers an API.
> 
> I am not sure what's different between "API" and GDB/MI, which is also an API
> or some sort.

I think I spelled that out pretty clearly. The library providing the API
solves the problem, so that every implementation doesn't have to.

> >Now front ends share the benefits of a common api, rather than every
> >front end dealing uniquely with all these issues, which is unrealistic.
> >
> >Now GDB can change independent of the protocol. GDB can look at what
> >features it is affecting in the API while developing it's internal features.
> >It's a win win situation.
> >
> >The API doesn't have to be internal to GDB. It could be gdbwire, a layer
> >that sits on top of GDB. That's the goal I'm pursuing in my spare time
> >for CGDB.
> >
> >However, based on your comments about JSON, and the fact that the python
> >api is the latest development in automating GDB, I'm not even sure how
> >appropriate it is to write a front end on GDB using MI. Can anyone speak
> >to the long term viability of this protocol? I'd hate to port CGDB to
> >GDB/MI only to be told that it's been superseded by a new protocol.
> >     http://www.cygwin.com/ml/gdb/2003-02/msg00070.html
> 
> I mention JSON in part because GDB/MI grammar is rather similar to it
> already. Saying "it's just JSON" would mean GDB folks don't have to deal
> with insignificant syntax matters.

But now all N front ends need to be modified to handle mi1, mi2 or json.

> Also, it would make it rather easy
> to add a Python function callable by frontend that would output data
> frontend can parse - using JSON support in Python is way easier than
> Python binding for GDB ui_ machinery.

Agreed. I plan on wrapping gdbwire with swig to provide python api's.

In the short term, you might see some emails for me, asking about
specific oddities in the GDB/MI protocol. This will be an an effort to
provide a robust API. In the long term, we'll see how many edge case's
there really are and perhaps decide where to go from there.

Thanks!
Bob Rossi