Yes both could be added, but it would hurt perfs to keep track of all the
seen names...esp if it is a large json.
2015-04-29 14:50 GMT+02:00 Martin Grebac <martin.grebac_at_oracle.com>:
> Could be, more interesting I think it would be in the profile definition
> for unmarshalling, where there should be a possibility to reject non I-JSON
> messages soonest in the stack - that I think would fall to JSON-P category,
> too.
> MartiNG
>
> On 29.04.15 14:42, Martin Vojtek wrote:
>
>> Actually I think JSON-P can help at least with unique names of
>> properties. I can imagine that JSON-P could provide option to enforce
>> uniqueness of names of properties (in terms of key/value - keys).
>>
>> MartinV
>>
>> On Tue, Apr 28, 2015 at 2:21 PM, Eugen Cepoi <cepoi.eugen_at_gmail.com
>> <mailto:cepoi.eugen_at_gmail.com>> wrote:
>>
>> +JSON-P EG
>>
>> I don't remember seeing I-JSON being discussed on the jsonp ML.
>> But perhaps this spec is more at the databinding level and doesn't
>> need to be implemented in jsonp.
>>
>>
>> 2015-04-28 14:01 GMT+02:00 Romain MB <rmannibucau_at_tomitribe.com
>> <mailto:rmannibucau_at_tomitribe.com>>:
>>
>> 2015-04-28 13:53 GMT+02:00 Martin Grebac
>> <martin.grebac_at_oracle.com <mailto: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 <mailto: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
>> >
>>
>>
>>
>>
> --
> Martin Grebac, SW Engineering Manager
> Oracle Czech, Prague
>
>