2015-04-28 13:53 GMT+02:00 Martin Grebac <martin.grebac_at_oracle.com>:
> 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
>
Was more in term of design. If I use byte[] then I don't expect the
serializer to *automatically* create a String. If i want a base64
string then I would have used a String directly IMO. Moreover if then
I use a byte[][], does it serialize it as String[] or really byte[][]?
In first case it will not match much cases IMO (and break default
expectations) and in second case it is not consistent with byte[]
serialization. So globally I would prefer to provide out of the box a
converter/serializer (whatever name we use) to allow to convert it to
base64url instead of having it implicitly.
> 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
>