Luke Kanies <[email protected]> writes:
> On Oct 13, 2010, at 3:25 PM, Markus Roberts wrote:
...sorry this is late in the picture, but I am catching up on older messages.
>>> Is this going to be contributed upstream to the json developers?
>>>
>> I can try. From the very limited looking into it I did, there appears to
>> be a moderately strong { unicode == correct, anything else == wrong } bias
>> in the project, to the extent that they disallow some documented parts of
>> json (e.g. "\x## ") that are explicitly designed to make life easier for
>> Latin-1 users.
>
> :/ Thanks.
A JSON "message" is explicitly specified to be a UTF-8 encoded string of
characters, so anything that tries to convey data outside that encoding should
rightly be pushed back by upstream.
Personally, I think that any encoding to transport arbitrary binary data in
PSON / JSON should rightly live in the application layer, as there are
arbitrarily many ways that could be done "right", so PSON having helpers is
probably also undesirable.
(I would probably have aimed to transform whatever 8-bit locale encoding into
UTF-8 and decoded back on the client side, so that *only* the very edges of
the system know anything about non-Unicode data. This is based on my
experience that doing *anything* else will send you insane in the long term,
because multiple encodings in the core of the product lead to something
breaking in a nasty, hard to debug, hard to support way eventually.)
Daniel
--
✣ Daniel Pittman ✉ [email protected] ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
