Return-Path: X-Original-To: apmail-ignite-dev-archive@minotaur.apache.org Delivered-To: apmail-ignite-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 7D85117374 for ; Wed, 30 Sep 2015 08:01:02 +0000 (UTC) Received: (qmail 24975 invoked by uid 500); 30 Sep 2015 08:01:01 -0000 Delivered-To: apmail-ignite-dev-archive@ignite.apache.org Received: (qmail 24932 invoked by uid 500); 30 Sep 2015 08:01:01 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 24921 invoked by uid 99); 30 Sep 2015 08:01:01 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Sep 2015 08:01:01 +0000 Received: from zulu.local (unknown [77.234.149.122]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id ED3901A022D for ; Wed, 30 Sep 2015 08:01:00 +0000 (UTC) Subject: Re: Introducing "compatibility level" concept. To: dev@ignite.apache.org References: From: =?UTF-8?Q?Branko_=c4=8cibej?= Organization: The Apache Software Foundation Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAAXNSR0IArs4c6QAAADBQTFRF IhsbCy0qZjoVOVRoeFxSAIKBzXQiAKaibYiewnk7nn9z0qCTgL3i87Ep6Kx/+tHBsrE+zgAAAjZJ REFUOMvF0jFoE1EYB/CzjWlqIzaTjqVIBifRRWyG0t5iUqlLyFpCeXBgKg5yq6A4degUDJjoUDpc 1Qt4Ux94B11SOLB0KGS4discpbkORTCn9/m9d3fvLhXnvuHu3f+Xx/veyyfZfLSdZHzgicSfeyw4 JISwdz8FT6M8lM8Ceg385Dlhs+cC9sQCDn0B78QCogzwN+sxfHGOIXBbRGkNAM4cZymGtgNsDPgz cByxon3EEm1TLmvAlghoHOO3CZSa+IQ/vF6JV8tgKOMow78gRgL2/+EIvATOUtB3SSdMg4GXgrbn uk0uLiGdoCHKbX4E+t1FUTqn1AtIdPJebssDQ64YANSQyyaQNyUOFs0ijMsMFnOPTahPLXKYowtY 08MfCP7vR7hRnc5zmPK7CDYYbHcbC7tHuyFA94U/1LYZaJpu/sxACHMwvwZljTLY0TbNk4x+zuEt yC3MfCM6uSIvfwur0itFL4FA2Yal8BzLfnYV4EIGwEPAk7o5zIcnvzHMEjwJrrhAKK7on6IrsfRJ 7A53BhaK+CL7fj6+q/sPeOvcDTtoZTxpUYsFeIknrOXep3p3l7Ua+8sZ5FPQKyKwWi+DfROTU7ny C1/9UhpeY7K287WJCzbsNPQm2S6Yk4PSCNhWM2r3nD0K9liYb6yPgCRJhSzPrxUK0yUBVk1VX0lj s7MzGZyp0wImMK/e8rHbz2soL+O+2r1dxfGsAmBcx0lNjS/RUhlUC7gRn1wGMdQ7Vw1/AReW/RN3 xFWdAAAAAElFTkSuQmCC Message-ID: <560B96C9.204@apache.org> Date: Wed, 30 Sep 2015 10:01:13 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 30.09.2015 09:51, Vladimir Ozerov wrote: > Igniters, > > Normally we are trying to maintain backward compatibility with previous > versions. But it is not always possible. > > E.g. we are about to release portable protocol. There are lots suggestions > how to optimize it, but all of them are relatively hard to implement. It > would not be a problem if are able to improve it iteratively from release > to release while still allowing for different versions (e.g. 1.5 and 1.6) > to communicate. > > What if we add a top-level property "*compatibility level*" allowing user > to "downgrade" some parts of the system to communicate with earlier > versions? That's likely to be a huge pain to maintain. The problem is that it doesn't force you to think about compatibility too much, and you'll end up having any number of incompatible protocols that you'll have to maintain simultaneously. There's an IMO better way: define the protocol to be natrually extensible, and introduce a capability exchange step. Map protocol extensions to capabilities (these can represented as simple tokens, or whatever), then make the client and server use any capabilities that are common to both. We do this in Subversion; that's how a 1.9 server can work with a 1.0 client but the same server will work much better (with more features available) with a 1.9 client. And the other way around, of course. -- Brane