2015-04-29 15:12 GMT+02:00 Martin Vojtek <voytoo_at_gmail.com>:
> Don't see problem supporting (in default mapping) the following point (and
> actually it was the original proposal before I-JSON discussion):
> - support only root objects/arrays by default
>
Not a problemjust modern JSON spec support "primitives" too I
think.That said using a mapper for primitives is quite weird.
> So the only point to agree upon is base64url. I don't have strong opinion
> about it. My impression is that binary data is not so common case. Maybe I
> am wrong.
>
> Interoperability is about interacting with JSON documents produced by
> different tools (in Java or different languages) and about JSON documents
> used in different scenarios (like JSON in URL).
>
> Thanks to JDK 8 there is no problem with Base64Url from implementation point
> of view.
>
> After some investigation I see some advantages of Base64Url over Base64 and
> binary data, the strongest point is maybe that base64 encoding uses
> characters that do not work well in URLs and sometimes HTTP headers.
>
> There is raising number of specifications using base64url, e.g.
> http://self-issued.info/docs/draft-ietf-oauth-json-web-token.html
>
Agree on the status but the point is mappers are also often used for
not url usages (where this doesn't make much sense). Security is
surely the most common field where it is done but I know very few
other domains which do it without "base64-ifying" the whole json (ie
we don't really care).
What about my idea of using a spec "converter". This way we are I-JSON
compliant without activating it by default. Having a bit like jaxb a
DataConverter SPI could make it smooth.
wdyt?
> MartinV
>
>
> On Tue, Apr 28, 2015 at 1:53 PM, Martin Grebac <martin.grebac_at_oracle.com>
> wrote:
>>
>> On 27.04.15 19:26, Romain MB wrote:
>>>
>>> 2015-04-27 18:38 GMT+02:00 Martin Grebac <martin.grebac_at_oracle.com>:
>>>>
>>>> On 24.04.15 20:54, Martin Vojtek wrote:
>>>>>
>>>>> I think that the result of the discussion is as follows:
>>>>>
>>>>> 1. support of string values for big numbers by default
>>>>> 2. support the override of properties by default
>>>>> 3. fail fast when non-unique property (after override and rename) is
>>>>> found
>>>>> 4. define default algorithm for override (based on java mechanism) and
>>>>> check uniqueness of properties (not affecting performance)
>>>>> 5. Do not enable I-JSON by default due to the following recommendations
>>>>> - support only root objects/arrays by default
>>>>> - serialize binary data to base64 by default
>>>>
>>>> To me, none of the 2 reasons above seem strong enough to not support
>>>> I-JSON
>>>> by default. Binary data is a specific usecase which is most often going
>>>> to
>>>> be configured based on specific needs, and root objects are limitation
>>>> of
>>>> current version of JSON-P as well (and I assume of some other parsers,
>>>> too,
>>>> otherwise the requirement would not be in I-JSON), so clients using
>>>> JSON-P
>>>> would have hard time parsing the default JSON Binding output.
>>>
>>> Not sure I fully get you. Ok about root objects point - this one is
>>> not that important I agree. That said from my understanding I-JSON
>>> recommands to use base64url by default (did I misunderstand?). If so I
>>> would prefer we don't follow this point as already explained in
>>> another mail.
>>
>> Thanks, I'm looking for the reasons why not to. The reasons for following
>> the recommendation is that base64url has its advantages, such as it is
>> leveraged within JSON security (encryption/signature) standards, and for
>> similar reasons it is a recommendation within I-JSON. Against, I found this
>> (let me know if I missed some other reasons, the thread is rather long):
>>
>> - byte data as base64: on johnzon we discussed it and I didn't want it
>> cause it was far from Java - that said it is not a super common type
>> so not sure it is that important
>>
>> I'm not sure what does it mean far from Java. SE8 gives options to
>> encode/decode to base64 or base64url:
>> https://docs.oracle.com/javase/8/docs/api/java/util/Base64.html
>>
>> You are right this is not a requirement, but recommendation, so there is
>> an option to opt out of this specific item (and/or some other ones within
>> I-JSON). Definition of recommendation is 'there may exist valid reasons in
>> particular circumstances to ignore a particular item, but the full
>> implications must be understood and carefully weighed before choosing a
>> different course'.In my view, I don't see the reasons for opting out (at
>> least not yet).
>>
>> MartiNG
>>
>