+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>:
> 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
> >
>