--- 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
>
>
>

On Mon, Feb 20, 2012 at 6:12 PM, rkalla123 <rkalla@...> wrote:

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

Hi! Is it still this doc:

https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/\
edit

that one hasn't been edited since September?

A couple comments, both positive:

> * no int64 length support, (REASON), not every platform plays nice with
64-bit. ...
> decode the format contents correctly. (WORKAROUND) just break
> the data payload into an array of multiple STRING or HUGE's.

A second workaround option is to use doubles for such cases.

> * signed length values, (REASON), numeric types in UBJSON
> are all signed.

While i think it's an unfortunate limitation, i think it is the right thing
to do for UBJSON. It used to bug the hell out of me that Google' v8 JS
engine doesn't support unsigned numbers, but i've since gotten over it and
just use doubles as a proxy when i _have_ to deal with large integers.

:)

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal


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

On Mon, Feb 20, 2012 at 6:35 PM, Stephan Beal <sgbeal@...> wrote:

> Hi! Is it still this doc:
>
>
>
https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/\
edit
>

Sorry, ignore the dumb question. i was still waiting on my netbook do load
that doc when i wrote that, and just now saw that the top of that doc
references the latest draft.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal


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

Tatu,

Thank you for the pointer; wasn't familiar with Vints. Looking at it now.

Best,
Riyad

--- In json@yahoogroups.com, Tatu Saloranta <tsaloranta@...> wrote:
>
> 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
> >
> >
> >
>

Stephan,

No problem; your feedback are still very applicable and much appreciated.

The additional view-point on the signed/unsigned issue was exactly what I was
hoping for. My primary goal has always been simplicity and I know at least from
the Java world, going with unsigned values would have made the impl distinctly
*not* simple (and an annoying API).

So I am glad to get some validation there that I am not alienating every other
language at the cost of Java.

Best,
Riyad

--- In json@yahoogroups.com, Stephan Beal <sgbeal@...> wrote:
>
> On Mon, Feb 20, 2012 at 6:35 PM, Stephan Beal <sgbeal@...> wrote:
>
> > Hi! Is it still this doc:
> >
> >
> >
https://docs.google.com/document/d/12SimAfBVcl8Fd-lr_SSBkM5B_PyEhDRfhgu1Lzvfpfw/\
edit
> >
>
> Sorry, ignore the dumb question. i was still waiting on my netbook do load
> that doc when i wrote that, and just now saw that the top of that doc
> references the latest draft.
>
> --
> ----- stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
>
> [Non-text portions of this message have been removed]
>

On Mon, Feb 20, 2012 at 9:42 AM, rkalla123 <rkalla@...> wrote:
> Stephan,
>
> No problem; your feedback are still very applicable and much appreciated.
>
> The additional view-point on the signed/unsigned issue was exactly what I was
hoping for. My primary goal has always been simplicity and I know at least from
the Java world, going with unsigned values would have made the impl distinctly
*not* simple (and an annoying API).
>
> So I am glad to get some validation there that I am not alienating every other
language at the cost of Java.

For what it is worth, I also consider support for only signed values a
good thing.

-+ Tatu +-

Maybe it is useful to have a look at how this is implemented in Javascript,
where JSON originally comes from. In Javascript you really need to define arrays
and objects, there is no implicit creation of arrays/objects.

I think implicitly creating arrays is quite tricky. For example, if you look at
   jsondoc["foo"][1]["bar"] = "harhar";
the type of the key (String or Number) determines if an object or an array will
be created...

I think it is better force explicit creation of arrays and objects, that will
not lead to misconceptions.

Jos


--- In json@yahoogroups.com, 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
>

wjosdejong scripsit:

> I think implicitly creating arrays is quite tricky. For example,
> if you look at
>   jsondoc["foo"][1]["bar"] = "harhar";
> the type of the key (String or Number) determines if an object or an
> array will be created...

On the contrary, I think this is a very good idea.  It's called
"autovivification" in Perl, and is very convenient.  It is particularly
nice that the static type of the key determines what sort of JSON object
to make.

--
John Cowan    cowan@...    http://ccil.org/~cowan
This great college [Trinity], of this ancient university [Cambridge],
has seen some strange sights. It has seen Wordsworth drunk and Porson
sober. And here am I, a better poet than Porson, and a better scholar
than Wordsworth, somewhere betwixt and between.  --A.E. Housman

Hi,
 
I have a general question on JON outputs and usage. I was a
flex developer for quite a bit of time and now I am planning to move my
application to JS+HTML.
All the call that were RPC in flex mode was made to support
REST now. The output is a jSON and I make AJAX calls and with the help of
JQuery I am able to work on. It is good and working fine.
 
Now I have a standardization question.
I currently have about 15 calls (it
may increase). Is it advised to have a same JSON o/p pattern for all the calls?
Or is it okay even if independent calls have different formats.
Ex:
Login:  [ I just need the single value Key in the
output]
errorCode: null
errorMessage: null
key: "ABCD_1234"
result: "OK"
rootCause: null
status: "OK"
 
List:  [ I need all the “entryId’s from result to be into a
select box may be]
errorCode: null
errorMessage: null
key: null
result: "[{"entryId":"test","entryValue":"Testing"},{"entryId":"Run","entryValu\
e":"Running"},{"entryId":"work","entryValue":"working"},{"entryId":"marktest","e\
ntryValue":"Mark's
play pen"},{"entryId":"kill","entryValue":"Killing"}]"
rootCause: null
status: "OK"
 
Now, I am parsing the result field
of JSON (using parseJSON) and then working on it. However the other fields of
the parent JSON are useless in the LIST call (like key, error etc). I still had
the same template of JSON that I used for login to have it same for all the
routines. This makes me inform anyone that the point to catch is in RESPONSE of
JSON. Is this okay? Or do you suggest to have separate JSON pattern for each
call? and avoid parsing pattern and use the native JSON output.
Since I am currently in the development
stage, I would not hesitate to make a change to make it work industry standard.
Thanks!

Response and guidance is greatly appreciated.
 
  
Cheers,
Venkat.

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

On Wed, Mar 14, 2012 at 5:59 PM, Venkat M <venkat_yum@...> wrote:

> **
>
> Now I have a standardization question.
> I currently have about 15 calls (it
> may increase). Is it advised to have a same JSON o/p pattern for all the
> calls?
>

i have a bit of experience in this area, e.g.:

https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/\
view
http://whiki.wanderinghorse.net/

and personally recommend using an evelope+body model, for both the requests
and response. i've tried the approach you're using (from what i
understand), and IMO it's not as scalable. It works fine for small APIs,
but i have come to prefer the extra level of an envelope for
framework/global-level properties and a payload/body for the app-level data
because it ensures that both the clients and the framework won't step on
each other's data (i.e. they have separate namespaces). The above document
demonstrates what i currently use in my various JSON back-ends. Rather than
roll your own, you might want to pick some library which already handles
such communication, leaving the client to only deal with creating the
requests and handling the responses. If you're interested, write me
off-list and i can give you a JS class i've been evolving the past several
years (and actively use on at least 5 projects) which provides a generic
client-side API for handling arbitrary JSON-based back-ends.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal


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

I'm proud to announce that MJSON v1.4 has been released!

M's JSON parser, a small, lightweight FLOSS library that handles documents
written in the JSON data interchange format. It's written in standard ISO C,
which means that it may run in any platform which is targeted by C compiler.

This release features minor bug fixes.

M's JSON parser can be downloaded at:
https://sourceforge.net/projects/mjson/

Rui Maciel

Hi All,
 
I have a basic question on consuming a rest web service. It
would be great if someone can help me out. Thanks in advance.
 
I have a web service definition as below.
 
Login Call
definition:
 
<resource path="/Login">
<method id="Login" name="POST">
<request>
<representation mediaType="application/json"/>
</request>
<response>
<representation mediaType="application/json"/>
</response>
</method>
</resource>
 
I make a JQuery
Ajax call like
 
$('#softlogin').click(function() {
          //alert('Login Check - With User Values');
             var uid = $('#username').val();
             var pwd = $('#password').val();
          $.ajax({
             url: 'http://localhost:8080/Services/Login',
             type: 'POST',
             async: 'async',
             data: JSON.stringify({'userid':uid,'password':pwd}),
             contentType: "application/json",
             dataType: "json",
             success: function(data){ 
               if (data.status == 'OK')
{
                 key = data.key;
                 document.cookie = "session_key"+ "="+ key;
                 //alert('Success -
finally'); 
                 $('#content').html('User:
'+ uid + '  &  Session Key :'+data.key);
               }
            }
         }).error(function()
{
           alert('An error Occoured');
         });
      });
 
Once the Login call is success, I am setting up the cookie
session_key with the Key that is returned in the Login call success.
 
And to Logout.
 
The web service definition is like
 
<resource path="/Logout">
<method id="Logout" name="POST">
<request>
<param xmlns:xs="http://www.w3.org/2001/XMLSchema" name="Cookie" style="heade\
r" type="xs:string" path="session_key"/>
</request>
<response>
<representation mediaType="*/*"/>
</response>
</method>
</resource>
 
In JQuery Ajax I write like
 
function getCookie(c_name)
      {
      var i,x,y,ARRcookies=document.cookie.split(";");
      for (i=0;i<ARRcookies.length;i++)
      {
        x=ARRcookies[i].substr(0,ARRcookies[i].indexOf("="));
        y=ARRcookies[i].substr(ARRcookies[i].indexOf("=")+1);
        x=x.replace(/^\s+|\s+$/g,"");
        if (x==c_name)
          {
          return unescape(y);
          }
        }
      }
     
      $('#termmodule').click(function()
{
           var session_key = getCookie("session_key");
           //alert('Cookie fetched is:' + session_key);
           $.ajax({
             url: 'http://localhost:8080/Services/Logout’,
             type: 'POST',
             async: 'async',
             data: JSON.stringify({'session_key':session_key}),
             //headers: {'Cookie' : session_key},
             contentType: "application/json",
             dataType: "json",
             success: function(data){ 
               if (data.status == 'OK')
{
                 alert('Session Logged out);
                 $('#content').html(data);
               }
            }
         }).error(function()
{
           alert('An error Occoured');
         });
      });
 
This is not working out. It fails. I am not sure why.
Is this the right way we pass cookie parameter.
 
I was also given the testing snippet from REST web service
developer like:
 
Response res =
given().cookie("session_key",
session_key).post("http://localhost:8080/Services/Logout");
It is with cookie
 
Please help me.
 
Cheers,
Venkat.

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

I'm not really sure this is the right forum for this question. Can I
recommend stack overflow for questions of this kind?

Cheers,

Dave.

On Mon, Apr 2, 2012 at 9:31 PM, Venkat M <venkat_yum@...> wrote:

> **
>
>
> Hi All,
>
> I have a basic question on consuming a rest web service. It
> would be great if someone can help me out. Thanks in advance.
>
> I have a web service definition as below.
>
> Login Call
> definition:
>
> <resource path="/Login">
> <method id="Login" name="POST">
> <request>
> <representation mediaType="application/json"/>
> </request>
> <response>
> <representation mediaType="application/json"/>
> </response>
> </method>
> </resource>
>
> I make a JQuery
> Ajax call like
>
> $('#softlogin').click(function() {
>           //alert('Login Check - With User Values');
>              var uid = $('#username').val();
>              var pwd = $('#password').val();
>           $.ajax({
>              url: 'http://localhost:8080/Services/Login',
>              type: 'POST',
>              async: 'async',
>              data: JSON.stringify({'userid':uid,'password':pwd}),
>              contentType: "application/json",
>              dataType: "json",
>              success: function(data){
>                if (data.status == 'OK')
> {
>                  key = data.key;
>                  document.cookie = "session_key"+ "="+ key;
>                  //alert('Success -
> finally');
>                  $('#content').html('User:
> '+ uid + '  &  Session Key :'+data.key);
>                }
>             }
>          }).error(function()
> {
>            alert('An error Occoured');
>          });
>       });
>
> Once the Login call is success, I am setting up the cookie
> session_key with the Key that is returned in the Login call success.
>
> And to Logout.
>
> The web service definition is like
>
> <resource path="/Logout">
> <method id="Logout" name="POST">
> <request>
> <param xmlns:xs="http://www.w3.org/2001/XMLSchema
> " name="Cookie" style="header" type="xs:string" path="session_key"/>
> </request>
> <response>
> <representation mediaType="*/*"/>
> </response>
> </method>
> </resource>
>
> In JQuery Ajax I write like
>
> function getCookie(c_name)
>       {
>       var i,x,y,ARRcookies=document.cookie.split(";");
>       for (i=0;i<ARRcookies.length;i++)
>       {
>         x=ARRcookies[i].substr(0,ARRcookies[i].indexOf("="));
>         y=ARRcookies[i].substr(ARRcookies[i].indexOf("=")+1);
>         x=x.replace(/^\s+|\s+$/g,"");
>         if (x==c_name)
>           {
>           return unescape(y);
>           }
>         }
>       }
>
>       $('#termmodule').click(function()
> {
>            var session_key = getCookie("session_key");
>            //alert('Cookie fetched is:' + session_key);
>            $.ajax({
>              url: 'http://localhost:8080/Services/Logout’,
>              type: 'POST',
>              async: 'async',
>              data: JSON.stringify({'session_key':session_key}),
>              //headers: {'Cookie' : session_key},
>              contentType: "application/json",
>              dataType: "json",
>              success: function(data){
>                if (data.status == 'OK')
> {
>                  alert('Session Logged out);
>                  $('#content').html(data);
>                }
>             }
>          }).error(function()
> {
>            alert('An error Occoured');
>          });
>       });
>
> This is not working out. It fails. I am not sure why.
> Is this the right way we pass cookie parameter.
>
> I was also given the testing snippet from REST web service
> developer like:
>
> Response res =
> given().cookie("session_key", session_key).post("
> http://localhost:8080/Services/Logout");
> It is with cookie
>
> Please help me.
>
> Cheers,
> Venkat.
>
> [Non-text portions of this message have been removed]
>
>
>


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

Jansson 2.3.1 has been released. This release fixes minor bugs and
documentation issues.

For a full list of changes, see:

   http://www.digip.org/jansson/doc/2.3/changes.html#version-2-3-1

Download source: http://www.digip.org/jansson/releases/jansson-2.3.1.tar.gz
View documentation: http://www.digip.org/jansson/doc/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

Hi all,

I have just released version 1.0 of JSON Editor Online:

http://jsoneditoronline.org <http://jsoneditoronline.org>

JSON Editor Online is a tool to easily edit and format JSON online. JSON
is displayed in a clear, editable treeview and in formatted plain text.

I hope the tool will be useful for you.

Suggestions for improvements are always welcome!

Jos


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

Cool project:
Would it be possible to have changes synced from left<->right when ever
I've finished edited or during at some intervals?

//JT


2012/4/21 wjosdejong <wjosdejong@...>

> **
>
>
> Hi all,
>
> I have just released version 1.0 of JSON Editor Online:
>
> http://jsoneditoronline.org <http://jsoneditoronline.org>
>
> JSON Editor Online is a tool to easily edit and format JSON online. JSON
> is displayed in a clear, editable treeview and in formatted plain text.
>
> I hope the tool will be useful for you.
>
> Suggestions for improvements are always welcome!
>
> Jos
>
> [Non-text portions of this message have been removed]
>
>
>



--
--
Jonas Tärnström
Product Manager
• e-mail: jonas.tarnstrom@...
• skype: full name "Jonas Tärnström"
• phone: +46 (0)734 231 552

ESN Social Software AB
www.esn.me


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

Thanks. Automatically updating the left/right side would be nice indeed. So far
I didn't do that, it is a little bit tricky: when handling large files (say
10000 lines) it gets slow, and then your browser "hangs" while syncing. I don't
know yet how to solve that nicely. Maybe make it an option, or automatically
turn off auto-syncing when the browser detects that it takes more than 100ms or
so, or smartly detect idle moments and use that to sync.

Besides that I still have a lot of ideas in mind: implementing shortcut keys,
implement undo/redo, store last state, load/save files from disk or url,
implement schema validation, etc.

Jos


--- In json@yahoogroups.com, Jonas T�rnstr�m <jonas.tarnstrom@...> wrote:
>
> Cool project:
> Would it be possible to have changes synced from left<->right when ever
> I've finished edited or during at some intervals?
>
> //JT
>
>
> 2012/4/21 wjosdejong <wjosdejong@...>
>
> > **
> >
> >
> > Hi all,
> >
> > I have just released version 1.0 of JSON Editor Online:
> >
> > http://jsoneditoronline.org <http://jsoneditoronline.org>
> >
> > JSON Editor Online is a tool to easily edit and format JSON online. JSON
> > is displayed in a clear, editable treeview and in formatted plain text.
> >
> > I hope the tool will be useful for you.
> >
> > Suggestions for improvements are always welcome!
> >
> > Jos
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
>
> --
> --
> Jonas T�rnstr�m
> Product Manager
> � e-mail: jonas.tarnstrom@...
> � skype: full name "Jonas T�rnstr�m"
> � phone: +46 (0)734 231 552
>
> ESN Social Software AB
> www.esn.me
>
>
> [Non-text portions of this message have been removed]
>

On Wed, Apr 25, 2012 at 2:28 AM, loki.astari@... <
loki.astari@...> wrote:

> **
> namespace ThorsAnvil { namespace Serialize { namespace Json {
> template<> struct JsonSerializeTraits<MyClass>
>

Here's a similar API, modelled after libs11n (http://s11n.net):

http://fossil.wanderinghorse.net/repos/nosjob/index.cgi/wiki?name=s11n

--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal


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

Hi all,

I tried searching for a FAQ but failed to find one so I hope it is OK to post
about my C++ JSON Serializer/De-Serializer here.

I reviewed a couple of alternative C++ libraries for JSON parsing but found non
adequate (in terms of ease of use). So I built my own:

I have posted my project on Git-Hub
<https://github.com/Loki-Astari/ThorsSerializer> and placed the code in the
public domain
<https://github.com/Loki-Astari/ThorsSerializer/blob/master/COPYRIGHT>.

Note:
   The code is still Alpha (I have only tested in my own code base (though there
are extensive unit tests provided)).
   Know deficiencies: The parser currently assumes UTF-8 input.

Objective:
==========
The objective is to make serialization/de-serialization of C++ object to/from
JSON trivial.

This means:
     1. does not build a JSON object. Reads data directly into C++ object.
     2. In normal usage there should be NO need to write any code.
     3. User should not need to understand JSON or validate its input.
     4. Should work seamlessly with streams.
     5. Standard containers should automatically work

Note: I tried to post example usage here but the formatting worked against me
and it looked really bad.

See the README:  
https://github.com/Loki-Astari/ThorsSerializer/blob/master/README
and the test.cpp:
https://github.com/Loki-Astari/ThorsSerializer/blob/master/test.cpp

I am also getting the code reviewed here:
http://codereview.stackexchange.com/questions/11138/json-serializer



Enjoy Loki.