MI fine-grained versioning

At the moment, MI does not have any mechanism to announce
supported
features. For example, I have a patch to add
"frozen" variable objects. To support
such feature in a backward-compatible fashion, the frontend
must know if that
features is supported by the given gdb binary.

Using version number is not very reliable -- for example if
you use the CVS state
of gdb, the version number is not yet bumped.

Yet another approach is to "detect" presence of
feature by trying some commands,
or by trying commands with some new options, or by
constructing more contrived test
cases. However that's troublesome.

How about adding new MI command that returnes list of
supported fine-grained features.
For example:

	-list-features
	^done,result=["frozen_variables","info_path_
expression"]

The MI manual would contain a section listing all feature
names and briefly documenting them.

Comments?

- Volodya

On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus
wrote:
> 
> At the moment, MI does not have any mechanism to
announce supported
> features. For example, I have a patch to add
"frozen" variable objects. To support
> such feature in a backward-compatible fashion, the
frontend must know if that
> features is supported by the given gdb binary.
> 
> Using version number is not very reliable -- for
example if you use the CVS state
> of gdb, the version number is not yet bumped.
> 
> Yet another approach is to "detect" presence
of feature by trying some commands,
> or by trying commands with some new options, or by
constructing more contrived test
> cases. However that's troublesome.
> 
> How about adding new MI command that returnes list of
supported fine-grained features.
> For example:
> 
> 	-list-features
>
	^done,result=["frozen_variables","info_path_
expression"]
> 
> The MI manual would contain a section listing all
feature names and briefly documenting them.

Great idea!

There are a few gothcha's. For instance, each command can
support
several parameters, so you might want to report on that. But
more
tricky, is when a command adds an output field that the
front end cares
about. An example of this would be that the -break-list
command has
always existed, but the -break-list command added fullpath
functionality
later on it it's life. How would you handle this, if at all?

Thanks,
Bob Rossi

On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus
wrote:
> Yet another approach is to "detect" presence
of feature by trying some commands,
> or by trying commands with some new options, or by
constructing more contrived test
> cases. However that's troublesome.
> 
> How about adding new MI command that returnes list of
supported fine-grained features.
> For example:
> 
> 	-list-features
>
	^done,result=["frozen_variables","info_path_
expression"]
> 
> The MI manual would contain a section listing all
feature names and briefly documenting them.
> 
> Comments?

If you want to do this, it sounds like this is the right way
- compare
to the qSupported I recently added for the remote protocol. 
I guess
this is the logical place to add a list of supported MI
versions,
too...

-- 
Daniel Jacobowitz
CodeSourcery

On Monday 18 December 2006 18:39, Bob Rossi wrote:
> On Mon, Dec 18, 2006 at 06:35:33PM +0300, Vladimir Prus
wrote:
> > 
> > At the moment, MI does not have any mechanism to
announce supported
> > features. For example, I have a patch to add
"frozen" variable objects. To support
> > such feature in a backward-compatible fashion, the
frontend must know if that
> > features is supported by the given gdb binary.
> > 
> > Using version number is not very reliable -- for
example if you use the CVS state
> > of gdb, the version number is not yet bumped.
> > 
> > Yet another approach is to "detect"
presence of feature by trying some commands,
> > or by trying commands with some new options, or by
constructing more contrived test
> > cases. However that's troublesome.
> > 
> > How about adding new MI command that returnes list
of supported fine-grained features.
> > For example:
> > 
> > 	-list-features
> >
	^done,result=["frozen_variables","info_path_
expression"]
> > 
> > The MI manual would contain a section listing all
feature names and briefly documenting them.
> 
> Great idea!
> 
> There are a few gothcha's. For instance, each command
can support
> several parameters, so you might want to report on
that. 

Yes. For example if -var-registers end up being

	-var-create --registers

we'd need a feature name.

> But more 
> tricky, is when a command adds an output field that the
front end cares
> about. An example of this would be that the -break-list
command has
> always existed, but the -break-list command added
fullpath functionality
> later on it it's life. How would you handle this, if at
all?

That's actually easy. If a frontend can handle the extra
field locally,
then we don't need new element in -list-features. If it
cannot, we need new element.
This "can" and "cannot" is determined by
hacking the relevant support in KDevelop.
If an author of some other frontend wants new item in
-list-features, that element
is added too. It's generally easier  to add new elements to
-list-features as frontend
authors request, then argue about "inherent" need
to announce a specific change.

- Volodya

 > > How about adding new MI command that returnes
list of supported
 > > fine-grained features.  For example:
 > > 
 > > 	-list-features
 > >
	^done,result=["frozen_variables","info_path_
expression"]
 > > 
 > > The MI manual would contain a section listing all
feature names and
 > > briefly documenting them.
 > 
 > Great idea!
 > 
 > There are a few gothcha's. For instance, each command
can support
 > several parameters, so you might want to report on
that. But more
 > tricky, is when a command adds an output field that
the front end cares
 > about.

In the manual we already explain that front ends should be
able to handle
extra fields in MI output.  The front end would need to do
this just
to handle -list-features.

 >         An example of this would be that the
-break-list command has
 > always existed, but the -break-list command added
fullpath functionality
 > later on it it's life. How would you handle this, if
at all?

Clearly it can't be retrospective.  I think it's a good idea
and would be
more convenient than bumping the level for small changes.

-- 
Nick                                           http://www.inet.net.n
z/~nickrob

On Tue, Dec 19, 2006 at 08:47:35AM +1300, Nick Roberts
wrote:
>  > > How about adding new MI command that
returnes list of supported
>  > > fine-grained features.  For example:
>  > > 
>  > > 	-list-features
>  > >
	^done,result=["frozen_variables","info_path_
expression"]
>  > > 
>  > > The MI manual would contain a section
listing all feature names and
>  > > briefly documenting them.
>  > 
>  > Great idea!
>  > 
>  > There are a few gothcha's. For instance, each
command can support
>  > several parameters, so you might want to report
on that. But more
>  > tricky, is when a command adds an output field
that the front end cares
>  > about.
> 
> In the manual we already explain that front ends should
be able to handle
> extra fields in MI output.  The front end would need to
do this just
> to handle -list-features.

Yes, this should be obvious. I'm suggesting that the front
end might
rely on a particular field to be sent from an MI command to
consider it
a valid 'version'. Anyways, a good solution to this problem
was already
given on the list.

Bob Rossi