Oops, I mentioned that to the benchmarker, I thought he altered the benchmark.
 You can see the benchmark to libjson fully parsing in the comment of the thread
he posted on my
sourceforge: http://sourceforge.net/projects/libjson/forums/forum/1119661/topic/\
4756047



________________________________
  From: Rob Meijer <pibara@...>
To: json@yahoogroups.com
Sent: Thursday, November 24, 2011 12:34 AM
Subject: Re: [json] c++ library benchmark

This benchmark seems to test the wrong thing. A library that is lazy in
parsing and pre-serializes on each update would likely perform poorly in
real operation but would outperform all others according to this benchmark.
On Nov 22, 2011 4:09 PM, "jonathan wallace" <ninja9578@...> wrote:

> **
>
>
> Hello,
> I was sent a message on sourceforge a while ago about someone doing a
> benchmark test of the most popular c++ json libraries.
>
> He compared json_spirit (Boost), CAJUN, and libjson.  He attempted to
> include jsoncpp in his tests, but said he couldn't get it to compile.
>
> I was sent the results this weekend:
> http://lijoblogs.blogspot.com/2011/11/comparison-and-benchmark-of-c-json.html
>
> I was surprised that json_spirit performed so poorly considering it's part
> of Boost.  CAJUN ran more than five times faster than it and libjson ran
> almost FIVE HUNDRED times faster than it.
>
> Jon
>
> [Non-text portions of this message have been removed]
>
> 
>


[Non-text portions of this message have been removed]



------------------------------------

Yahoo! Groups Links



[Non-text portions of this message have been removed]

Does the value type have to be a string, or does it support the other
types, e.g. true/false, numbers, objects, arrays, etc.  I believe it should
be any valid json.  Otherwise it's of limited usefulness.  Some examples:

original document:
{
   "foo": "bar"
}

patch:
[
    { "add": "/foo/obj", "value": {} },
    { "add": "/foo/obj/bool", "value": true },
    { "add": "/foo/obj/int", "value": 123 },
    { "add": "/foo/obj/dec", "value": 123.12 },
    { "add": "/foo/arr", "value": [] },
    { "add": "/foo/arr/0", "value": "x" }
]

resulting document:
{
   "foo": "bar",
   "obj": {
          "bool" : true,
          "int": 123,
          "dec": 123.12
   },
   "arr": [ "x" ]
}


[Non-text portions of this message have been removed]

Sorry, messed up the patch portion a little bit.  It should be this instead:
  patch:
  [
     { "add": "/obj", "value": {} },
     { "add": "/obj/bool", "value": true },
     { "add": "/obj/int", "value": 123 },
     { "add": "/obj/dec", "value": 123.12 },
     { "add": "/arr", "value": [] },
     { "add": "/arr/0", "value": "x" }
  ]


--- In json@yahoogroups.com, Ted Elliott <elliott.ted@...> wrote:
>
> Does the value type have to be a string, or does it support the other
> types, e.g. true/false, numbers, objects, arrays, etc.  I believe it should
> be any valid json.  Otherwise it's of limited usefulness.  Some examples:
>
> original document:
> {
>   "foo": "bar"
> }
>
> patch:
> [
>    { "add": "/foo/obj", "value": {} },
>    { "add": "/foo/obj/bool", "value": true },
>    { "add": "/foo/obj/int", "value": 123 },
>    { "add": "/foo/obj/dec", "value": 123.12 },
>    { "add": "/foo/arr", "value": [] },
>    { "add": "/foo/arr/0", "value": "x" }
> ]
>
> resulting document:
> {
>   "foo": "bar",
>   "obj": {
>          "bool" : true,
>          "int": 123,
>          "dec": 123.12
>   },
>   "arr": [ "x" ]
> }
>
>
> [Non-text portions of this message have been removed]
>

It supports any value type, including objects and arrays.

Paul

On Thu, 2011-12-01 at 09:05 -0500, Ted Elliott wrote:

>
>
> Does the value type have to be a string, or does it support the other
> types, e.g. true/false, numbers, objects, arrays, etc. I believe it
> should
> be any valid json. Otherwise it's of limited usefulness. Some
> examples:
>
> original document:
> {
> "foo": "bar"
> }
>
> patch:
> [
> { "add": "/foo/obj", "value": {} },
> { "add": "/foo/obj/bool", "value": true },
> { "add": "/foo/obj/int", "value": 123 },
> { "add": "/foo/obj/dec", "value": 123.12 },
> { "add": "/foo/arr", "value": [] },
> { "add": "/foo/arr/0", "value": "x" }
> ]
>
> resulting document:
> {
> "foo": "bar",
> "obj": {
> "bool" : true,
> "int": 123,
> "dec": 123.12
> },
> "arr": [ "x" ]
> }
>
> [Non-text portions of this message have been removed]
>
>
>
>
>



[Non-text portions of this message have been removed]

I've submitted the latest JSON Patch Internet-Draft, posted here:

http://tools.ietf.org/html/draft-pbryan-json-patch-03

It includes new "move" and "test" operations, and addresses some
phrasing issues that were raised. Your review and feedback will be
appreciated.

Paul


[Non-text portions of this message have been removed]

I quickly submitted another JSON Patch Internet-Draft, now posted here:

http://tools.ietf.org/html/draft-pbryan-json-patch-04

It now provides a usage example for each operation, fixes a few overt
typographical errors and cleans up further ambiguous phrasing.

Your review and feedback would be appreciated.

Paul


[Non-text portions of this message have been removed]

Interesting proposal, it could be useful, but it still need some work ;-)

I'm not sure if it's best using pure path / url syntax to find the target
element or the JavaScript dot notation. As JSON means JavaScript Object
Notation, maybe JSON Patch could use the JSON Path proposal
(https://developer.mozilla.org/en/JSON/JSONPath) for which we can already find
some implementations:
- http://code.google.com/p/jsonpath/downloads/list
- http://search.cpan.org/~tobyink/JSON-Path-0.101/lib/JSON/Path.pm
-
http://rest-assured.googlecode.com/svn/tags/1.4.5/apidocs/com/jayway/restassured\
/path/json/JsonPath.html
- http://www.sitepen.com/blog/2008/03/17/jsonpath-support/

I think it would be really more readable when you target Array indexes

in your example
{
     { "add": "/foo/1", "value": "qux" }
}
is more readable like this for many languages
{
     { "add": "foo[1]", "value": "qux" }
}
(even those using round brackets)

Maybe JSON Path does a bit too much, but at least array slices are better
handled

About the operations, I think more informations may be required.

Are JSON Patch services meant to support cross-typed operations? Which behavior
should we expect?
-> sure that saying no-support is easier

When a path is not applicable to a JSON document, should the implementation try
to build the missing part of the structure?
-> saying "no" would surely be easier, but some may be frustrated ;-)

What if there is a scalar value at some point of the path in the targeted JSON
document? Should it be overridden?
-> an error in the current state, but if the previous point is supported... it
might support a media type parameter (ex: "application/json-patch;
override=true")





--- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
>
> I quickly submitted another JSON Patch Internet-Draft, now posted here:
>
> http://tools.ietf.org/html/draft-pbryan-json-patch-04
>
> It now provides a usage example for each operation, fixes a few overt
> typographical errors and cleans up further ambiguous phrasing.
>
> Your review and feedback would be appreciated.
>
> Paul
>
>
> [Non-text portions of this message have been removed]
>

Thanks for the feedback. My comments inline:

On Mon, 2011-12-05 at 09:15 +0000, alexandre_morgaut wrote:

>
>
> Interesting proposal, it could be useful, but it still need some
> work ;-)
>
> I'm not sure if it's best using pure path / url syntax to find the
> target element or the JavaScript dot notation. As JSON means
> JavaScript Object Notation, maybe JSON Patch could use the JSON Path
> proposal (https://developer.mozilla.org/en/JSON/JSONPath) for which we
> can already find some implementations:
> - http://code.google.com/p/jsonpath/downloads/list
> - http://search.cpan.org/~tobyink/JSON-Path-0.101/lib/JSON/Path.pm
> -
>
http://rest-assured.googlecode.com/svn/tags/1.4.5/apidocs/com/jayway/restassured\
/path/json/JsonPath.html
> - http://www.sitepen.com/blog/2008/03/17/jsonpath-support/

The first draft of JSON Patch actually used JSON Path. Since JSON Path
was not standardized, I had to choose to try to standardize JSON Path or
do something else. For other reasons, we also needed a syntax that would
be very easy to express in a URI fragment identifier. JSON Schema
developed a simple syntax, which was very straightforward to implement—
much simpler even if you only kept dot and bracket notation and dumped
the rest. This was spun-off into the JSON Pointer specification.


> I think it would be really more readable when you target Array indexes
>
> in your example
> {
> { "add": "/foo/1", "value": "qux" }
> }
> is more readable like this for many languages
> {
> { "add": "foo[1]", "value": "qux" }
> }
> (even those using round brackets)
>
> Maybe JSON Path does a bit too much, but at least array slices are
> better handled
>
> About the operations, I think more informations may be required.
>
> Are JSON Patch services meant to support cross-typed operations? Which
> behavior should we expect?
> -> sure that saying no-support is easier

Not sure what you mean by cross-typed operations. Can you replace a
number with a string or object? Yes.


> When a path is not applicable to a JSON document, should the
> implementation try to build the missing part of the structure?
> -> saying "no" would surely be easier, but some may be frustrated ;-)

The latest text in draft 04 attempts to address this question and
results in the answer being no: "The location must reference one of: the
root of the target document, a member to add to an existing object, or
an element to add to an existing array."


> What if there is a scalar value at some point of the path in the
> targeted JSON document? Should it be overridden?
> -> an error in the current state, but if the previous point is
> supported... it might support a media type parameter (ex:
> "application/json-patch; override=true")

No, by the text I quoted above, it cannot be overridden.

Paul



[Non-text portions of this message have been removed]

> The first draft of JSON Patch actually used JSON Path. Since JSON Path
> was not standardized, I had to choose to try to standardize JSON Path or
> do something else. For other reasons, we also needed a syntax that would
> be very easy to express in a URI fragment identifier. JSON Schema
> developed a simple syntax, which was very straightforward to implementâ€"
> much simpler even if you only kept dot and bracket notation and dumped
> the rest. This was spun-off into the JSON Pointer specification.

I think JSONPath is kind of a de facto standard. It was chosen by ebay to create
its new SQL variant ( http://ql.io/examples )

I like JSON Schema but I'm not fan of this JSON Pointer draft. The JSON Path or
Pointer reference something inside the representation (HTTP Body). So yes, it
could be inserted with benefits in the fragment part of the URL as it is
proposed for plain text (RFC 5147) or W3C Media fragments.

Fragments are always URL encoded either if they look as a URL like path or a
JavaScript like path... I agree it'd be great to have the author propose a draft
to the IETF


> Not sure what you mean by cross-typed operations. Can you replace a
> number with a string or object? Yes.

I meant something like a "add" of a number to a string

Regards,
Alexandre

On Mon, 2011-12-05 at 17:56 +0000, alexandre_morgaut wrote:


> > The first draft of JSON Patch actually used JSON Path. Since JSON
> Path
> > was not standardized, I had to choose to try to standardize JSON
> Path or
> > do something else. For other reasons, we also needed a syntax that
> would
> > be very easy to express in a URI fragment identifier. JSON Schema
> > developed a simple syntax, which was very straightforward to
> implementâ€"
> > much simpler even if you only kept dot and bracket notation and
> dumped
> > the rest. This was spun-off into the JSON Pointer specification.
>
> I think JSONPath is kind of a de facto standard. It was chosen by ebay
> to create its new SQL variant ( http://ql.io/examples )
>
> I like JSON Schema but I'm not fan of this JSON Pointer draft. The
> JSON Path or Pointer reference something inside the representation
> (HTTP Body). So yes, it could be inserted with benefits in the
> fragment part of the URL as it is proposed for plain text (RFC 5147)
> or W3C Media fragments.
>
> Fragments are always URL encoded either if they look as a URL like
> path or a JavaScript like path... I agree it'd be great to have the
> author propose a draft to the IETF
>
> > Not sure what you mean by cross-typed operations. Can you replace a
> > number with a string or object? Yes.
>
> I meant something like a "add" of a number to a string


No, this specification does not support mathematical, logical or string
operations.

Paul



[Non-text portions of this message have been removed]

{"hello":"bson"}
\x15 \x00 \x00 \x00 \x02 h e l l o \x00 \x05 \x00 \x00 \x00 b s o n \x00 \x00

I already read from this link : http://bsonspec.org/#/specification
but stil confused.
Can anyone explain what \x15 & why start \x15?
what \x02 before "hello"?
what \x05?
thanks in advance

Wrong mailing list -- you probably want to join
http://groups.google.com/group/bson since this is related to BSON, not
json.

-+ Tatu +-

On Sun, Dec 11, 2011 at 8:13 PM, zaqi <slash_jak@...> wrote:
>                        {"hello":"bson"}
> \x15 \x00 \x00 \x00 \x02 h e l l o \x00 \x05 \x00 \x00 \x00 b s o n \x00 \x00
>
> I already read from this link : http://bsonspec.org/#/specification
> but stil confused.
> Can anyone explain what \x15 & why start \x15?
> what \x02 before "hello"?
> what \x05?
> thanks in advance
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>

I'm hoping someone can help explain the rationale behind a couple of
points in the JSON specification:

1. 8bit content-transfer-encoding for UTF-8

RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
was 8bit selected rather than binary content-transfer-encoding? This
limits the length of JSON strings to 994 octets.

2. Non-unique object members

RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
selected rather than MUST?

Paul

On Sun, Jan 1, 2012 at 9:50 PM, Paul C. Bryan <paul.bryan@...> wrote:
> I'm hoping someone can help explain the rationale behind a couple of
> points in the JSON specification:
>
> 1. 8bit content-transfer-encoding for UTF-8
>
> RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
> was 8bit selected rather than binary content-transfer-encoding? This
> limits the length of JSON strings to 994 octets.

Hmmh? Where does 994 come from?

> 2. Non-unique object members
>
> RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
> selected rather than MUST?

I assume this was to allow implementations to choose whether they keep
track of all seen names or not: this can add non-trivial overhead for
storage requirements, especially when processing JSON data streams.

-+ Tatu +-

Paul C. Bryan scripsit:

> RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible."

I think that statement is just a false assertion rather than a normative
restriction.

> This limits the length of JSON strings to 994 octets.

Nobody imposes any such limit.

> 2. Non-unique object members
>
> RFC 4627: "The names within an object SHOULD be unique." Why was
> SHOULD selected rather than MUST?

That's a very good question.

--
We are lost, lost.  No name, no business, no Precious, nothing.  Only empty.
Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
fishes, for a poor creature, and they say death.  So wise they are; so just,
so very just.  --Gollum        cowan@...  http://ccil.org/~cowan

Tatu Saloranta scripsit:

> > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
> > was 8bit selected rather than binary content-transfer-encoding? This
> > limits the length of JSON strings to 994 octets.
>
> Hmmh? Where does 994 come from?

From RFC 2045:

2.8.  8bit Data

    "8bit data" refers to data that is all represented as relatively
    short lines with 998 octets or less between CRLF line separation
    sequences [RFC-821]), but octets with decimal values greater than 127
    may be used.  As with "7bit data" CR and LF octets only occur as part
    of CRLF line separation sequences and no NULs are allowed.

> > 2. Non-unique object members
> >
> > RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
> > selected rather than MUST?
>
> I assume this was to allow implementations to choose whether they keep
> track of all seen names or not: this can add non-trivial overhead for
> storage requirements, especially when processing JSON data streams.

Good point.

--
With techies, I've generally found              John Cowan
If your arguments lose the first round          http://www.ccil.org/~cowan
     Make it rhyme, make it scan                 cowan@...
     Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

On Sun, 2012-01-01 at 23:11 -0800, Tatu Saloranta wrote:

> Hmmh? Where does 994 come from?

Sorry, 996 octets. I think.

Per RFC 2045 §2.8, 8bit data is "...represented as relatively short
lines with 998 octets or less between CRLF line separation sequences..."

Given that a JSON string must be encapsulated in quotation marks (2
octets), this seems to limit the number of octets that can be expressed
in a UTF-8 encoded JSON string to 996 octets.

Paul

On Sun, Jan 1, 2012 at 11:32 PM, Paul C. Bryan <paul.bryan@...> wrote:
> On Sun, 2012-01-01 at 23:11 -0800, Tatu Saloranta wrote:
>
>> Hmmh? Where does 994 come from?
>
> Sorry, 996 octets. I think.
>
> Per RFC 2045 §2.8, 8bit data is "...represented as relatively short
> lines with 998 octets or less between CRLF line separation sequences..."
>
> Given that a JSON string must be encapsulated in quotation marks (2
> octets), this seems to limit the number of octets that can be expressed
> in a UTF-8 encoded JSON string to 996 octets.

I am quite sure this was not the intent -- such limit would indeed
render JSON pretty useless.

-+ Tatu +-

--- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
>
> I'm hoping someone can help explain the rationale behind a couple of
> points in the JSON specification:
>
> 1. 8bit content-transfer-encoding for UTF-8
>
> RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible." Why
> was 8bit selected rather than binary content-transfer-encoding? This
> limits the length of JSON strings to 994 octets.

JSON does not impose such a limit.

> 2. Non-unique object members
>
> RFC 4627: "The names within an object SHOULD be unique." Why was SHOULD
> selected rather than MUST?

This was so that ECMAScript's eval function could act as a JSON parser. I think
it should have been MUST.

Thanks for the explanations. A follow-up question below...

On Mon, 2012-01-02 at 13:12 +0000, douglascrockford wrote:

> --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
> >
> > I'm hoping someone can help explain the rationale behind a couple of
> > points in the JSON specification:
> >
> > 1. 8bit content-transfer-encoding for UTF-8
> >
> > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit compatible."
> Why
> > was 8bit selected rather than binary content-transfer-encoding? This
> > limits the length of JSON strings to 994 octets.
>
> JSON does not impose such a limit.

Why isn't such a limit implied by specifying "8bit" in the IANA
Recommendations?

> > 2. Non-unique object members
> >
> > RFC 4627: "The names within an object SHOULD be unique." Why was
> SHOULD
> > selected rather than MUST?
>
> This was so that ECMAScript's eval function could act as a JSON
> parser. I think it should have been MUST.

Paul

Bump. Is specifying "8bit" in the IANA recommendations not normative?

Paul

On Mon, 2012-01-02 at 08:52 -0800, Paul C. Bryan wrote:

>
>
> Thanks for the explanations. A follow-up question below...
>
> On Mon, 2012-01-02 at 13:12 +0000, douglascrockford wrote:
>
> > --- In json@yahoogroups.com, "Paul C. Bryan" <paul.bryan@...> wrote:
> > >
> > > I'm hoping someone can help explain the rationale behind a couple
> of
> > > points in the JSON specification:
> > >
> > > 1. 8bit content-transfer-encoding for UTF-8
> > >
> > > RFC 4627: "When JSON is written in UTF-8, JSON is 8bit
> compatible."
> > Why
> > > was 8bit selected rather than binary content-transfer-encoding?
> This
> > > limits the length of JSON strings to 994 octets.
> >
> > JSON does not impose such a limit.
>
> Why isn't such a limit implied by specifying "8bit" in the IANA
> Recommendations?
>
> > > 2. Non-unique object members
> > >
> > > RFC 4627: "The names within an object SHOULD be unique." Why was
> > SHOULD
> > > selected rather than MUST?
> >
> > This was so that ECMAScript's eval function could act as a JSON
> > parser. I think it should have been MUST.
>
> Paul
>
>
>
>
>



[Non-text portions of this message have been removed]

Jansson 2.3 has been released. This release adds new features and
fixes some minor bugs and documentation issues.

Highlights:

- Add json_object_foreach() for more convenient iteration over
   objects.

- Add support for decoding any JSON value, not just arrays or
   objects. The support is enabled with the new JSON_DECODE_ANY
   flag. Patch by Andrea Marchesini.

- Add support for optional object keys with the "{s?o}" syntax to
   json_unpack() and friends.

For a more detailed overview of changes, see

   http://www.digip.org/blog/2012/01/jansson-2.3-released.html

Download source: http://www.digip.org/jansson/releases/jansson-2.3.tar.gz
View documentation: http://www.digip.org/jansson/doc/2.3/
Changes: http://www.digip.org/jansson/doc/2.3/changes.html#version-2-3


What is Jansson?
----------------

Jansson is a C library for encoding, decoding and manipulating JSON data.
It features:

* Simple and intuitive API and data model
* Comprehensive documentation
* No dependencies on other libraries
* Full Unicode support (UTF-8)
* Extensive test suite

Jansson is licensed under the MIT license.

For more details, see http://www.digip.org/jansson/.


Petri Lehtinen

https://www.p6r.com/articles/2012/01/30/p6r-kmip-toolkit-introduction/



Best,

Mark Joseph, Ph.D.
President
P6R, Inc
408-205-0361
mark@...
Skype: markjoseph_sc
   _____



[Non-text portions of this message have been removed]

JASON is just like JSON, but unlike JSON it can:

serialize objects with methods
serialize objects with cyclic references
understand Dates, Regexps, Booleans, etc, and restore them with .parse() with
their proper types/classes.
understand and serialize all the JS primitives, including undefined
properly recreate the holes in Arrays
JASON lets you pass objects as text between processes and/or threads.

Warning: unlike JSON, JASON is unsafe. You should only use it in contexts where
you have strong guarantees that the strings that you pass to the JASON parser
have been produced by a JASON formatter from a trusted source.

https://github.com/xk/JASON

--
Jorge.

I was hoping to get some feedback on a few changes I have planned for the
Universal Binary JSON Specification (http://ubjson.org) Draft 9 before I made
them official.

The group's help has been critical thus far in shaping the spec and I would
certainly appreciate the guidance once again.

CURRENT STATUS
--------------

The spec is currently at Draft 8 which I believe you guys have seen; the last
additions being the compact STRING, HUGE, ARRAY and OBJECT types (using 1-byte
lengths intead of 4-byte) in addition to the streaming-support for unbounded
containers.

Coming from that current place, I am working on the following changes that I
would like feedback on:


PROPOSED CHANGES

========================

1. Remove the concept of ARRAY or OBJECT (container types) having a length
argument at all and simply define the two container types with a beginning [A]
or [O] and an ending [E] marker currently used for "unbounded containers".

Alex, the author behind the simpleubjson implementation, pointed out that since
the container length argument doesn't convey any useful information besides
tracking the scope, it was redundant to support both the [E]-terminated
containers and containers with a child element count.

I should have removed the length argument from the container types in Draft 8
when I added streaming support, but it didn't dawn on me at the time.


========================


2. As a result of #1, remove the compact ARRAY and OBJECT representations ([a]
and [o] lowercased markers) - they are unnecessary now.


========================


3. There are 2 variable-length data types in UBJSON that define lengths: STRING
and HUGE.

Currently the lengths are defined as either a int8 or an int32 value depending
on the type-marker used (so there are duplicate definitions for STRING and HUGE
just like there were for ARRAY and OBJECT).

The change I am proposing here for both clarity and implementation
simplicity/normalization is to make the 'length' argument of the STRING and HUGE
types one of the Universal Binary JSON integer numeric types: int8, int16 or
int32.

So instead of:
[S][3][bob]

you would have:
[S][B][3][bob]

or

[S][i][7168][7,168 bytes representing a string...]

The cost is the added byte, but the win is support for a length between 1-byte
(int8) and 2.1 billion bytes (int32) as well as spec and implementation
simplification which I think are big wins.

There is some contention here though with the existing numeric types that I'd
like some feedback on to make sure I am not talking to myself inside an
echo-chamber here, namely:

* no int64 length support, (REASON), not every platform plays nice with 64-bit.
The lack of universal 64-bit number support was exactly what brought about the
creation of the HUGE type. A value that is not universally supported cannot be
part of the core spec such that some platforms cannot decode the format contents
correctly. (WORKAROUND) just break the data payload into an array of multiple
STRING or HUGE's.

* signed length values, (REASON), numeric types in UBJSON are all signed. This
makes working with them in languages like Java straight forward and easy to
grasp. It also makes the APIs straight forward for any libraries implementing
it. Trying to support unsigned values gets you into a work of pain where UBJSON
String's can actually be 4GB runs of characters but Java's String as well as
Java's arrays can only be signed 32-bit int in size. (WORKAROUND) same as above,
break the payload into 2GB chunks.

I am aware of these limitations and do not think they are show-stoppers at the
cost of making changes that are currently so simple to support on all platforms
but I wanted to get some verification from other smart people incase I missed
the boat here on something.


========================


4. As a result of #3, remove the compact STRING and HUGE representations ([s]
and [h] lowercased markers) - they are unnecessary now.


========================


These are the changes currently being analyzed right now for the Draft 9 spec. I
think the re-simplification to the spec (after its growth between Draft 4 and
Draft 8) are big wins here with minimal changes to existing implementations.

I think the re-use of the numeric types as lengths are a big win for
implementation logic as well. I know in the Java API it would remove duplication
complexity for me as well as the Python impl which would be nice.

Thank you all for your time, I appreciate it.

Best wishes,
Riyad


P.S.> If you have OT suggestions for the spec I am eager to hear them here or
you can email me at ubjson@... if you'd rather talk privately.

rkalla123 scripsit:

> I was hoping to get some feedback on a few changes I have planned for
> the Universal Binary JSON Specification (http://ubjson.org) Draft 9
> before I made them official.

They all look fine to me.

--
We do, doodley do, doodley do, doodley do,        John Cowan <cowan@...>
What we must, muddily must, muddily must, muddily must;
Muddily do, muddily do, muddily do, muddily do,    http://www.ccil.org/~cowan
Until we bust, bodily bust, bodily bust, bodily bust.  --Bokonon

A while ago I wrote the JsonMe++ wrapper library. Currently a wrapper
for the parsing part of the glib JSON C library.

https://github.com/pibara/jsonme--

JsonMe++ provides an API that heavily uses operator overloading, cast
operators and value semantic proxies to provide
a bit of a scripting language like API for parsing JSON.

Now I would like to continue working on JsonMe++ by expanding the API
with the possibility of also creating JSON
rather than just parsing it. Handling objects seems quite simple and
natural to do simply by adding some assignment
operators to the API.

Handling arrays however has got me a bit confused. Do I stick to an
API with as little as possible 'named', node level methods?
It does seem to have a lot of merit to keep the node API without named
methods, but this will require me to handle
sparse arrays, what might or might not be a good idea.

Basically I could make the API work like:

jsondoc["foo"][1]["bar"] = "harhar";

And let, if jsondoc was empty still, create a new json object with a
foo memeber that is a sparse array with an empty index 0 element
and an object index 1 element that has a "bar" member with value "harhar".

Alternatively I could make the API so that the above would need to be
expressed as:

jsondoc["foo"].append();
jsondoc["foo"].append()["bar"] = "harhar"

I don't know if one of these would be better, or if there would be a
third alternative that would be more suitable.
I would be very interested in learning what others think.

Rob

I'd say you may want not to abuse on overloading, which may make you API
harder to use, even though it first seems to be doing the opposite. Regards.
On Feb 20, 2012 8:09 AM, "Rob Meijer" <pibara@...> wrote:

> **
>
>
> A while ago I wrote the JsonMe++ wrapper library. Currently a wrapper
> for the parsing part of the glib JSON C library.
>
> https://github.com/pibara/jsonme--
>
> JsonMe++ provides an API that heavily uses operator overloading, cast
> operators and value semantic proxies to provide
> a bit of a scripting language like API for parsing JSON.
>
> Now I would like to continue working on JsonMe++ by expanding the API
> with the possibility of also creating JSON
> rather than just parsing it. Handling objects seems quite simple and
> natural to do simply by adding some assignment
> operators to the API.
>
> Handling arrays however has got me a bit confused. Do I stick to an
> API with as little as possible 'named', node level methods?
> It does seem to have a lot of merit to keep the node API without named
> methods, but this will require me to handle
> sparse arrays, what might or might not be a good idea.
>
> Basically I could make the API work like:
>
> jsondoc["foo"][1]["bar"] = "harhar";
>
> And let, if jsondoc was empty still, create a new json object with a
> foo memeber that is a sparse array with an empty index 0 element
> and an object index 1 element that has a "bar" member with value "harhar".
>
> Alternatively I could make the API so that the above would need to be
> expressed as:
>
> jsondoc["foo"].append();
> jsondoc["foo"].append()["bar"] = "harhar"
>
> I don't know if one of these would be better, or if there would be a
> third alternative that would be more suitable.
> I would be very interested in learning what others think.
>
> Rob
>
>


[Non-text portions of this message have been removed]

Thank you John for the feedback.

Anyone else have any thoughts? Stephan, Don, Tatu, Milo?

--- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
>
> rkalla123 scripsit:
>
> > I was hoping to get some feedback on a few changes I have planned for
> > the Universal Binary JSON Specification (http://ubjson.org) Draft 9
> > before I made them official.
>
> They all look fine to me.
>
> --
> We do, doodley do, doodley do, doodley do,        John Cowan <cowan@...>
> What we must, muddily must, muddily must, muddily must;
> Muddily do, muddily do, muddily do, muddily do,    http://www.ccil.org/~cowan
> Until we bust, bodily bust, bodily bust, bodily bust.  --Bokonon
>

One thing I did have in mind was that use of zigzag encoded VInts has
benefts, and is used by many (most?) new binary dataformats. It is
also not overly complex to use (although granted easy to get wrong at
first try).
Its main benefit is reduced size of data.

-+ Tatu +-

On Mon, Feb 20, 2012 at 9:12 AM, rkalla123 <rkalla@...> wrote:
> Thank you John for the feedback.
>
> Anyone else have any thoughts? Stephan, Don, Tatu, Milo?
>
> --- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
>>
>> rkalla123 scripsit:
>>
>> > I was hoping to get some feedback on a few changes I have planned for
>> > the Universal Binary JSON Specification (http://ubjson.org) Draft 9
>> > before I made them official.
>>
>> They all look fine to me.
>>
>> --
>> We do, doodley do, doodley do, doodley do,        John Cowan <cowan@...>
>> What we must, muddily must, muddily must, muddily must;
>> Muddily do, muddily do, muddily do, muddily do,    http://www.ccil.org/~cowan
>> Until we bust, bodily bust, bodily bust, bodily bust.  --Bokonon
>>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>