On Nov 7, 2014, at 11:30 AM, Garrett D'Amore <garr...@damore.org> wrote:
> The simple, IMO, answer for JSON numbers is to treat them as arbitrary > precision numbers. For nvlist conversion, that means they can be integers > fully capable of representing 64-bits. The simple answer is to not use JSON numbers and the Alyseo team followed this sage advice (thanks!) -- richard > > Sadly, *JavaScript* cannot express 64-bit integers without loss of precision. > Which is one of the things that makes JavaScript a rotten language for > systems programming; Joyent’s use of node.js notwithstanding. But what would > you expect of a scripting language designed for use in creating interactive > web pages? > > Taken as a text format, rather than snippets of JavaScript, JSON is totally > fine in this regard. > > Otherwise, you have to resort to encoding numbers as strings, or accepting > data loss. > > I believe when faced with decoding 64-bit (or larger) numeric integers, most > JavaScript implementations settle on the latter. I’ve not checked what > node.js does. > > (In the real world, we rarely have to deal with full 64-bit values — I > believe that JavaScript can represent up to around 2^53 without loss of > precision. Fortunately, this is usually sufficient. For now.) > > My suggested approach would only penalize those situations and environments > that cannot actually express the full precision values. If you think that > this is a concern, then you need to choose another runtime! > > - Garrett > > >> On Sep 25, 2014, at 8:39 AM, Richard Elling >> <richard.ell...@richardelling.com> wrote: >> >> On Sep 24, 2014, at 10:55 PM, Robert Mustacchi <r...@joyent.com> wrote: >> >>> On 9/24/14 22:51 , Matthew Ahrens wrote: >>>> On Mon, Sep 22, 2014 at 9:34 AM, Yacine Kheddache < >>>> yacine.khedda...@alyseo.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I know this is an old topic : https://github.com/zfsonlinux/zfs/issues/740 >>>>> >>>>> And also that -H argument can help in some cases, also know all the talks >>>>> around libzfs, libzfs_core… >>>>> >>>>> But during the first OpenZFS European Conference in Paris : >>>>> http://www.meetup.com/OpenZFS-Europe/events/177038202/ >>>>> >>>>> We have had pretty nice conversation with users and developers and it >>>>> seems that all or most can agree on the fact it will be so simpler and >>>>> cleaner if all zfs / zpool outputs can be jsonify on request (specific arg >>>>> for this purpose)… >>>>> >>>>> So : >>>>> 1/ did I miss something and you guys have an alternative for this ? >>>>> 2/ if not, is the community think this is a valuable feature request ? >>>>> >>>>> I’m convince this could really help to bring new zfs lovers on board which >>>>> can contribute with nice addons. >>>>> >>>>> The howto (API on top of libzfs libzfs_core or changing commands >>>>> structures…) are still TBD if the community would like to move forward on >>>>> the topic ;-) But really think this need to go upstream… >>>>> >>>> Sounds like something that could be useful. If you implement this, let me >>>> know if you need any pointers, or if you'd like to discuss your design >>>> before you start implementing it. >>> >>> Other thing I'd add is that we added an nvlist to JSON output into >>> libnvpair in illumos and we have some prototype code that does the >>> parsing back into an nvpair. If that's something you're looking for, I >>> can get you in touch with folks about that. >> >> We've done similar. Now is a good time for collaboration. It would be nice to >> reach concensus by the OpenZFS conference in early November. >> >> The method is sound, the concensus is needed around the nvlist strongly-typed >> data conversion to/from JSON, which is almost, but not quite, untyped. Or, as >> I'm often heard lamenting, "JSON numbers are neither integers nor floating >> point, >> they are numbers." >> -- richard >> _______________________________________________ >> developer mailing list >> developer@open-zfs.org >> http://lists.open-zfs.org/mailman/listinfo/developer > _______________________________________________ developer mailing list developer@open-zfs.org http://lists.open-zfs.org/mailman/listinfo/developer
