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.

jsonsl aims for speed and simplicity in distribution and usage.

Consisting of one source file (jsonsl.c) and one header file (jsonsl.h),
there are no complex build systems to use and no need chasing around the
source tree to make modifications. Just drop in and link (of course, it
can also be built and used as a shared library, if one prefers)

jsonsl uses a stack/state model, with the states themselves being
'subclassable' so as to efficiently carry extra user information related
to each frame.

Features:

* Extensible and embeddable

* High performance (about as fast as YAJL)

* Flexible callback interface

* Streaming - does not buffer data and does not allocate memory beyond
initial structures

* JSONPointer extended search syntax. Find matching elements using
glob-like semantics

* Detailed error reporting

* ANSI C (I've gotten it to work on several unices and mingw32, but it
can probably work on MSVC too)

* Utility function to unescape strings

* Large set of JSON examples (used as part of jsonsl's test suite)


--- Goodies:

* Simple glib-based program converting JSON to XML (380 lines including
option parsing)

* Perl Module

jsonsl:

https://github.com/mnunberg/jsonsl

perl-JSON-SL

https://github.com/mnunberg/perl-JSON-SL

Translatation kindly provided
by Paul Cohen (Seibo Software Studios)

http://www.json.org/json-sv.html

There seem to be a growing number of tools & packages around that
implement some form of JSON streaming where multiple standard JSON
objects are delimited by extra newlines, e.g.

   { "id": 1, "foo": "bar" }
   { "id": 2, "foo": "baz" }
   ...

This format seems both pragmatic and useful, but is not JSON compliant
(i.e. doesn't parse with a standard JSON parser), so it seems
inappropriate to serve up as "application/json".   The NPM package
Request-JSONStream uses "application/jsonstream", Google searching
shows at least one use of "application/x-json-stream", and there are a
number of services that use "application/json" and expect clients to
just deal with it (cf.
https://github.com/senchalabs/connect/issues/538).

Since I'm about to make heavy use of this technique in a way that will
be a little difficult to unwind later I'd like if at all possible get
on board with whatever will become the standard (defacto or official).
Anyone aware of any efforts underway to standardize this, or
packages/services that have enough momentum to drive a standard in the
future?

--Ken

On Wed, May 23, 2012 at 11:10 PM, Ken Woodruff <ken.woodruff@...>wrote:

> **
>
> { "id": 1, "foo": "bar" }
> { "id": 2, "foo": "baz" }
> ...
>
> This format seems both pragmatic and useful, but is not JSON compliant
> (i.e. doesn't parse with a standard JSON parser)
>

Wouldn't a standards-compliant (or sane?) parser stop reading at the end of
the first object (implying that the first above is, strictly speaking,
standard JSON with extra crud at the end)?

If so... adding the convention "if the byte following the root node is a
newline or \r\n combination, attempt to parse remaining bytes as JSON..."
might be more or less all you need. Such an extension would need to address
what to do (or not do) with the consumed 1-2 bytes if they are _not_ \n or
\r\n, but those are details we'll leave to the spec writers...

Happy Hacking!

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


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

On Wed, May 23, 2012 at 5:10 PM, Ken Woodruff <ken.woodruff@...>wrote:

> **
>
>
> There seem to be a growing number of tools & packages around that
> implement some form of JSON streaming where multiple standard JSON
> objects are delimited by extra newlines, e.g.
>
> { "id": 1, "foo": "bar" }
> { "id": 2, "foo": "baz" }
> ...
>
> This format seems both pragmatic and useful, but is not JSON compliant
> (i.e. doesn't parse with a standard JSON parser), so it seems
> inappropriate to serve up as "application/json".   The NPM package
> Request-JSONStream uses "application/jsonstream", Google searching
> shows at least one use of "application/x-json-stream", and there are a
> number of services that use "application/json" and expect clients to
> just deal with it (cf.
> https://github.com/senchalabs/connect/issues/538).
>
> Since I'm about to make heavy use of this technique in a way that will
> be a little difficult to unwind later I'd like if at all possible get
> on board with whatever will become the standard (defacto or official).
> Anyone aware of any efforts underway to standardize this, or
> packages/services that have enough momentum to drive a standard in the
> future?
>
> --Ken
>
>

This is came up a while back, we were discussing streams of json over
sockets/tcp, in relation to json-rpc streams here:

https://groups.google.com/forum/?fromgroups#!msg/json-rpc/fd1_anYEnDs/5k_w5Vu9Xt\
MJ

Use of the ascii character 0x04 EOT was also an option others have
suggested in these discussions.

Using newlines seem like the same topic, just a different end of json
marker. There are a lot of ways to achieve this of course, EOL markers seem
as straight forward of a solution as any. The ability for a single bad json
object in the stream to corrupt parsing down the line always seemed like a
concern, perhaps unavoidable and unlikely at the same time?

I still feel like sending a json array with a parser capable of spinning
out parsed array values as soon as it can makes the most sense, like
SAX<http://en.wikipedia.org/wiki/Simple_API_for_XML> based
parsing. But I'll be glad to see a standard/best practice come of out this
thread.

--
Matt (MPCM)


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

I've just released a small lightweight JSON formatter written in C.
It doesn't try to validate. It doesn't buffer or call malloc making it suitable
for being placed in long running unix pipelines.

https://github.com/bsouther/jsonf


Thanks
-Ben

Ben scripsit:

> I've just released a small lightweight JSON formatter written in C.
> It doesn't try to validate. It doesn't buffer or call malloc making it
suitable for being placed in long running unix pipelines.

It actually does do stdio buffering; if it didn't, it would be dog-slow.

--
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              cowan@...
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

Thanks, John,
I'll remove the "no buffering" part from the description.

BTW: I like your Open Source License Wizard.

-Ben

--- In json@yahoogroups.com, John Cowan <cowan@...> wrote:
>
> Ben scripsit:
>
> > I've just released a small lightweight JSON formatter written in C.
> > It doesn't try to validate. It doesn't buffer or call malloc making it
suitable for being placed in long running unix pipelines.
>
> It actually does do stdio buffering; if it didn't, it would be dog-slow.
>
> --
> Values of beeta will give rise to dom!          John Cowan
> (5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
> to rename '.' or '..' entries; see              cowan@...
> http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)
>

Thanks to Dave Gamble, there is already a new version with a fix for a bug that
caused an extra line-break to appear after closing quotes.

There is also a port, by Dave, to Javascript up there now.
Thanks again, Dave.

-Ben

https://github.com/bsouther/jsonf


--- In json@yahoogroups.com, "Ben" <ben@...> wrote:
>
> Thanks, John,
> I'll remove the "no buffering" part from the description.
>
> BTW: I like your Open Source License Wizard.
>
> -Ben
>
> --- In json@yahoogroups.com, John Cowan <cowan@> wrote:
> >
> > Ben scripsit:
> >
> > > I've just released a small lightweight JSON formatter written in C.
> > > It doesn't try to validate. It doesn't buffer or call malloc making it
suitable for being placed in long running unix pipelines.
> >
> > It actually does do stdio buffering; if it didn't, it would be dog-slow.
> >
> > --
> > Values of beeta will give rise to dom!          John Cowan
> > (5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
> > to rename '.' or '..' entries; see              cowan@
> > http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)
> >
>