On Mon, 01 Feb 2010 18:08:27 +0100
Markus Armbruster <arm...@redhat.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> writes:
>
> > Feature negotiation allows clients to enable new QMP capabilities they
> > support and thus allows QMP to envolve in a compatible way.
> >
> > A capability is a new QMP feature and/or protocol change which is not part
> > of
> > the core protocol as defined in the QMP spec.
>
> Well, it becomes part of the protocol then. But I understand what you
> mean.
>
> > Feature negotiation is implemented by, among other changes, adding
> > mode-oriented support to QMP, which comprehends the following:
> >
> > o Two modes: handshake and operational
> > o All QMP Monitors start in handshake mode
> > o In handshake mode only commands to query/enable/disable QMP capabilities
> > are
> > allowed (there are few exceptions)
> > o Clients can switch to the operational mode at any time
> > o In Operational mode most commands are allowed and QMP capabilities changes
> > made in handshake mode take effect
> >
> > Please, note that we don't have any capability yet. So, the most visable
> > change in this series is that now Clients must switch to operational mode to
> > be able to issue 'regular' commands.
> >
> > Session example:
> >
> > """
> > {"QMP": {"capabilities": []}}
> >
> > { "execute": "query-qmp-mode" }
> > {"return": {"mode": "handshake"}}
> >
> > { "execute": "stop" }
> > {"error": {"class": "CommandNotFound", "desc": "The command stop has not
> > been found", "data": {"name": "stop"}}}
> >
> > { "execute": "qmp_capability_enable", "arguments": { "name": "foobar" } }
> > {"error": {"class": "InvalidParameter", "desc": "Invalid parameter name",
> > "data": {"name": "name"}}}
> >
> > { "execute": "qmp_switch_mode", "arguments": { "mode": "operational" } }
> > {"return": {}}
> >
> > { "execute": "query-qmp-mode" }
> > {"return": {"mode": "operational"}}
> >
> > { "execute": "stop" }
> > {"return": {}}
> >
> > """
>
> I don't doubt your design does the job. I just think it's overly
> general. I had something far more stupid in mind:
>
> client connects
> server -> client: version & capability offer (one message)
> again:
> client -> server: capability selection (one message)
> server -> client: either okay or error (one message)
> if error goto again
> connection is now ready for commands
>
> No modes. The distinct lack of generality is a design feature.
I like the simplicity and if we were allowed to change later I'd
do it.
The question is if we will ever want features to be _configured_
before the protocol is operational. In this case we'd need to
pass feature arguments through the capability selection command,
which will get ugly and hard to use/understand.
Mode oriented support doesn't have this limitation. Maybe we
won't never really use it, but it's safer.
