From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4875 invoked by alias); 16 Feb 2013 09:27:03 -0000 Received: (qmail 4840 invoked by uid 22791); 16 Feb 2013 09:27:02 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout23.012.net.il (HELO mtaout23.012.net.il) (80.179.55.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 16 Feb 2013 09:26:57 +0000 Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MIB00L00382HY00@a-mtaout23.012.net.il> for gdb-patches@sourceware.org; Sat, 16 Feb 2013 11:26:55 +0200 (IST) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MIB00L833KVHQ30@a-mtaout23.012.net.il>; Sat, 16 Feb 2013 11:26:55 +0200 (IST) Date: Sat, 16 Feb 2013 09:27:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH 1/5] Add annex in a async remote notification. In-reply-to: <511EFE76.4030506@codesourcery.com> To: Yao Qi Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83621ssj6n.fsf@gnu.org> References: <1358838232-13319-1-git-send-email-yao@codesourcery.com> <1358838232-13319-2-git-send-email-yao@codesourcery.com> <83fw1tod6e.fsf@gnu.org> <511EFE76.4030506@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00437.txt.bz2 > Date: Sat, 16 Feb 2013 11:35:18 +0800 > From: Yao Qi > CC: > > On 01/22/2013 04:05 PM, Eli Zaretskii wrote: > > Is it a good idea to have the optional part in the middle? If there > > are MI clients out there that support the previous form, they might > > now confuse ANNEX to be an EVENT. > > It can't be confused. The "optional" here means some notifications have > annexes and some don't. Given an notification, the annexes of it are > determined, and annex is separated with event by ":". Sorry, I don't follow your reasoning. My concern was about the following use case: . an old MI client that only supports the old "name:event" form . a notification is sent in the new form "name:annex:event" . the MI client only parses the first 2 parts, and confuses "annex" for "event" How can we be sure this can never happen? We have no idea what MI clients are out there, they are out of control of GDB development.