prataprc / jsondata Goto Github PK

TryFrom and TryInto are right now unstable. Once they have stabilised implement them for bool, i128, f64, String, Vec<Json>, Vec<Property> types.

For Travis continuous integration, QuickCheck is a nightly package, hence it can be tested only in nightly.

When JSON is the document format for databases, there shall always be some
need to define PartialOrd and Ord for JSON formated values. More specifically
we may need to figure out the following details -

• Sort order for different types - null, bool, number, string, array, object.
• Sort order for bool - false values sort before true values.
• Sort order for float
  • NaN sort before negative-infinity.
  • negative-infinity sort before all floating point values.
  • positive-infinity sort after all floating point values.
• For Strings, Unicode sort order or binary sort order.
• Should array size sort before array elements.
• Should object size sort before object elements.
• Minbound and Maxbound, especially useful when JSON is used in range queries.

Following list of operations can be implemented.

• Arithmetic operations, ADD, SUB, MUL, DIV, REM, NEG.
• Bitwise operations, SHL, SHR, BITAND, BITOR, BITXOR.
• Logical operations, NOT, AND, OR.
• Compare operations EQ, NE, LT, LE, GT, GE.
• Index operations.
• Range operations.

In case you need jsondata to be part of a proprietary distribution or to be part of a different license agreement, please post your request here or contact the author directly.

It looks like the following feature prevents the crate from compiling on stable Rust.

#![feature(total_cmp)]

Is it possible to work around this feature in order to get the crate to compile on stable? If not, is there an expected time frame for when this feature might make it into stable? I would really like to use the crate, but the dependence on nightly could become an issue.

From https://users.rust-lang.org/t/sort-order-for-json/24166/3

• Empty array shall sort before non empty arrays.
• f64 Negative ZERO shall short before f64 Positive ZERO.
• Remove Minbound and Maxbound and suggest Bound::Unbounded in the documentation.

Floats are serialized to JSON5 using {:e} formatting, which renders infinity as inf/-inf instead of Infinity/-Infinity.

Read API should begin with to_ or into_ or as_

Unicode specification for sorting string has this to say:

Because collation varies by language and not just by script, it is not possible to arrange the encoding for characters so that simple binary string comparison produces the desired collation order for all languages. Because multi-level sorting is a requirement, it is not even possible to arrange the encoding for characters so that simple binary string comparison produces the desired collation order for any particular language.

Note that the current implementation of Ord on JSON string simply does a byte-by-byte comparison.

Would be nice to add the following badges.

• Build passing, Travis continuous integration.
• Code coverage, codecov and coveralls.
• Crates badge
• Downloads badge
• License badge
• Rust version badge.
• Maintenance-related badges based on isitmaintained.com
• Documentation
• Gitpitch

Json-data serialization can be bench marked and compared with other serialization via
https://github.com/djkoloski/rust_serialization_benchmark

Values in jsondata::Json should not change in its hash value for any given hashing algorithm. Also the serialized form of jsondata::Json should not affect its hash value for any give hashing algorithm.

List of common hashing algorithm:

fasthash::city
fasthash::murmur3
SHA1

Parse an incoming stream of JSON text. This can have separate
implementation from parsing non-streaming JSON text to avoid performance
overheads for the later case.

JSON5 extends JSON specification.

• Object keys may be an ECMAScript 5.1 IdentifierName.
• Objects may have a single trailing comma.
• Arrays may have a single trailing comma.
• Strings may be single quoted.
• Strings may span multiple lines by escaping new line characters.
• Strings may include character escapes.
• Numbers may be hexadecimal.
• Numbers may have a leading or trailing decimal point.
• Numbers may be IEEE 754 positive infinity, negative infinity, and NaN.
• Numbers may begin with an explicit plus sign.
• Single and multi-line comments are allowed.
• Additional white space characters are allowed.

Refer: Full JSON5 specification

So that application can handle returned error values from publicly exposed API.

Benchmark JSON operations like:

• Arithmetic operations, ADD, SUB, MUL, DIV, REM, NEG.
• Bitwise operations, SHL, SHR, BITAND, BITOR, BITXOR.
• Logical operations, NOT, AND, OR.
• Compare operations EQ, NE, LT, LE, GT, GE.
• Index operations.
• Range operations.

JSON Strings can be unicode encoded and parsing them can be costly: For example

for r#""汉语 / 漢語; Hàn\b \tyǔ ""#

bench_string:  771 ns/iter (+/- 213)

By not supporting unicode encoded string, we can improve the performance of JSON deserialisation.

Right now parse_string() handles string parsing for JSON. Implement parse_ascii_string() as alternate feature.

Total ordering is complex for floating point numbers. Adding to that in JSON, due to mixed type of integer and floating-point, total ordering need to be worked out across both integers and floats.

A detailed description for total ordering is covered here
Also there is a discussion thread in users.rust-lang.org.