Luiz Capitulino <lcapitul...@redhat.com> writes: > On Mon, 01 Feb 2010 20:37:41 +0100 > Markus Armbruster <arm...@redhat.com> wrote: > >> Luiz Capitulino <lcapitul...@redhat.com> writes: >> >> > On Mon, 01 Feb 2010 18:08:27 +0100 >> > Markus Armbruster <arm...@redhat.com> wrote: [...] >> >> 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. >> >> Capability selection could be done as an object where the name/value >> pairs are capability/argument. If you need multiple arguments for a >> capability, make the capability's value an object. > > That's exactly what seems complicated to me, because besides performing > two functions (enable/configure) some feature setup could require > more commands to be done in a clear way.
What do you mean by "feature setup"? And how does it go beyond setting a bunch of parameters? > The async messages setup in the previous series was an example of this. I don't remember the details. Could you summarize? > As said we might never use this, but I wouldn't like to regret later. A somewhat plausible example for how it could be needed would help.
