Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of julian.reschke@gmx.de
 designates 213.165.64.23 as permitted sender)
Message-ID: <4EDCD32A.2070502@gmx.de>
Date: Mon, 05 Dec 2011 15:20:26 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Thomas Mueller <mueller@adobe.com>
CC: "dev@jackrabbit.apache.org" <dev@jackrabbit.apache.org>
Subject: Re: JSOP extension points, was: JSOP
References: <CB028A54.20B6F%mueller@adobe.com>
In-Reply-To: <CB028A54.20B6F%mueller@adobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2011-12-05 15:02, Thomas Mueller wrote:
> Hi,
>
>> Unless I'm missing something, a today's JSOP parsers will be unable to
>> parse future messages that contain an extension defined like the above,
>> as they won't know how to skip over it.
>
> What we currently don't have, and probably should add, is a way to
> negotiate the format / protocol version (for example in the first message,
> similar to the "HTTP/1.1" in "GET / HTTP/1.1").
>
> But generally, parsers shouldn't silently skip over things they don't
> understand, except if it's explicitly defined to be implementation
> specific / optional (#pragma and such). Could you provide examples of
> languages that do support such extension points?

Most XML-based formats do; the same applies to JSON -- it's the "must 
ignore" pattern.

The "must understand" pattern makes it very hard to deploy new things, 
as you can't use it until each recipient understands it (this is why, 
for instance, the HTTP Expect header field is a big failure).

Best regards, Julian