On Mon, Mar 18, 2019 at 10:04 PM Antoine Toulme
<[email protected]> wrote:
>
>
>
> > On Mar 18, 2019, at 9:59 PM, Tatu Saloranta <[email protected]> wrote:
> >
> > On Thu, Mar 7, 2019 at 9:03 PM Antoine Toulme <[email protected]> 
> > wrote:
> >>
> >> Hello all,
> >>
> >> I have recently worked with the SecureScuttlebutt group on implementing 
> >> their feeds.
> >> One of their requirements is to sign JSON messages. Instead of removing 
> >> all whitespace, they decided to use a pretty printer to format the message.
> >>
> >> They mention when pretty printing the JSON that they use a specific format 
> >> after this specification: 
> >> https://www.ecma-international.org/ecma-262/6.0/#sec-json.stringify
> >>
> >> I'll confess that I don't quite get the algorithm in there. Helpfully, the 
> >> SSB protocol guide 
> >> (https://ssbc.github.io/scuttlebutt-protocol-guide/#message-format) spells 
> >> it out for me:
> >>
> >>> In brief, the rules are:
> >>>
> >>> Two spaces for indentation.
> >>>
> >>> Dictionary entries and list elements each on their own line.
> >>>
> >>> Empty dictionaries appear as {} and empty lists appear as [].
> >>>
> >>> One space after the colon : for dictionary keys.
> >>>
> >>> Strings and numbers formatted according to the sections QuoteJSONString 
> >>> and ToString Applied to the Number Type.
> >>>
> >>> No trailing newline.
> >>
> >> Or, from their tests, they apply this function:
> >>>
> >>> JSON.stringify(msg, null, 2)
> >>
> >>
> >> I believe the indentation rule is custom to SSB. I also am chasing them on 
> >> the newline character used (they say it's `\n`). All those rules matter 
> >> since they're using those rules to sign data.
> >>
> >> That said, would the Jackson community be interested in using this format 
> >> (with the possibility to dictate different indent characters, different 
> >> newlines) as a pretty printer?
> >>
> >> Cheers,
> >>
> >> Antoine
> >
> > Don't everyone comment at once please... :-I
> >
> > I think I would like to see this as an option for 2.10. As to 3.0 it
> > could even become the default but that'd be up to debate.
> > From quick glance one difference I saw was that white space would only
> > be added after colon, not before; and another had to do with array
> > elements. Latter could be problematic for anyone who wants more
> > compact (but still readable) output I guess.
> >
> > -+ Tatu +-
>
> Sure. Would that be an alternate default pretty printer? Are the options I 
> mention above OK?

Options are fine, but I now noticed something that could be problematic:

> >>> Strings and numbers formatted according to the sections QuoteJSONString 
> >>> and ToString Applied to the Number Type.

`PrettyPrinter` does not have control over these aspects. It may or
may not be fundamental problem as there are formatting options that
may be set for `JsonGenerator`, but would probably need to be
documented so that it is clear that to get exact behavior intended may
require both use of specific "alt" PrettyPrinter and some
`JsonGenerator.Feature` settings.

-+ Tatu +-

-- 
You received this message because you are subscribed to the Google Groups 
"jackson-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to