On Tue, 02 Feb 2010 09:03:32 +0100 Markus Armbruster <arm...@redhat.com> wrote:
> 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? Not the best example since we agreed async messages setup could be done in operational mode, but in case other features will require it: 1. The async message feature _and_ each async message were disabled by default 2. You could enable async message feature with capability_enable 3. Then, each message should be enabled separately with async_message_enable The use case here is: a feature requires to be configured before the protocol is operational. It's possible to do this with a command like feature, but it'll get bloated over time.
