Hi Carsten & All, Think about following cases -
- old client <-> old server - old client <-> new server - new client <-> old server - new client <-> old server Now let's say there was change in server protocol format among versions. Best case would new Clients support both old and new server formats. And for the case of old client with new server, client must receive an error. To let above feature work, we need a method to communicate the version information. Since version of Standard Spec and Open Source are not same always and there is possiblity of having mutiple Open Source version per Standard Spec version, Open Source will have to know what other side supports before it takes a call to switch parser or encoder. Does it make sense? Regards Dwarka ---------------------------------------------------------------------------------- Software R&D Center | Convergence Team | IoT Lab Open Connectivity Foundation ? OSWG ? Spec Coordination TG Chair Iotivity Steering Group ? Advisory Committee -----Original Message----- From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Carsten Bormann Sent: Friday, December 09, 2016 3:11 PM To: "??? (Uze Choi)" Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] [Versioning] Add option number for IoTivity version On 9 Dec 2016, at 06:43, ??? (Uze Choi) <uzchoi at samsung.com> wrote: > > Presumably, When client with updated protocol want to communicate with > server, server can detect client protocol is new one. How does the behavior of the server change based on this information? What happens if the server does not know about the new protocol version? (If the behavior change is mandatory, the new client cannot interoperate with the older server.) The client request will need to make sense for servers implementing previous protocol versions. (If you don?t do that, clients cannot really use new protocol versions, because they might be running into older version servers.) This means the protocol version cannot really supply any crucial information. So, in summary, version numbers are great for making sure that a newer client does not interoperate with an older server (yes, that may sometimes be an objective). But they are not very good for evolving a protocol in a backwards-compatible way, which is what you?ll want to do in most cases. Gr??e, Carsten _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
