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

I've published a web page with some propositions to modify JSON at
http://json.marler.info <http://json.marler.info>
I wanted to post this so I could see what people think of these
propositions.  Any comments/suggestions/criticism are welcome.


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

I don't think this is a good idea. One of the best things, if not the best,
about JSON is the lack of a version number. The standard is frozen and will
never change, and because of that there is only one thing called JSON, and
everything that supports "JSON" today will support it tommorow, too.

Also, you haven't added omitting quotes round key names, and you've
introduced features JavaScript doesn't have, so I dislike it for that
reason anyway.

On 10 July 2012 20:32, johnnys <marler8997@...> wrote:

> **
>
>
> I've published a web page with some propositions to modify JSON at
> http://json.marler.info <http://json.marler.info>
> I wanted to post this so I could see what people think of these
> propositions. Any comments/suggestions/criticism are welcome.
>
> [Non-text portions of this message have been removed]
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

On Tue, Jul 10, 2012 at 12:35 PM, Andrew Faulds <ajfweb@...> wrote:
> I don't think this is a good idea. One of the best things, if not the best,
> about JSON is the lack of a version number. The standard is frozen and will
> never change, and because of that there is only one thing called JSON, and
> everything that supports "JSON" today will support it tommorow, too.
>
> Also, you haven't added omitting quotes round key names, and you've
> introduced features JavaScript doesn't have, so I dislike it for that
> reason anyway.

I second this.

If anyone wants to "modify" standard JSON, it is best done by
proposing a new standard since there is no practical way of
introducing alternative versions of JSON (as explained above).
Call it MyCoolDataFormat, StuffLikeJson whatever: nothing wrong in
proposing new formats that look a bit like existing ones.

-+ Tatu +-

On Tue, Jul 10, 2012 at 3:35 PM, Andrew Faulds <ajfweb@...> wrote:
> I don't think this is a good idea. One of the best things, if not the best,
> about JSON is the lack of a version number. The standard is frozen and will
> never change, and because of that there is only one thing called JSON, and
> everything that supports "JSON" today will support it tommorow, too.

That's a valid argument, but is it such a big deal given that anything
in software evolves and it's just natural to deal with versions?

His proposition 1 and 2 are something I'm sure many would be happy
with. One of the main virtues of JSON, to be easier to read and write
by humans, is hurt by quotes requirement in names and the inability to
use single quotes for strings. And there are parsers already that
support those so the "standard" is often not strictly respected
anyway.

> Also, you haven't added omitting quotes round key names, and you've
> introduced features JavaScript doesn't have, so I dislike it for that
> reason anyway.
>
> On 10 July 2012 20:32, johnnys <marler8997@...> wrote:
>
>> **
>>
>>
>> I've published a web page with some propositions to modify JSON at
>> http://json.marler.info <http://json.marler.info>
>> I wanted to post this so I could see what people think of these
>> propositions. Any comments/suggestions/criticism are welcome.
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>



--
http://www.kobrix.com, http://kobrix.blogspot.com,
http://sharegov.blogspot.com, http://ilovefencing.com

"Damn! The world is big!"

-- Heleni Daly

It is a big deal, JSON is supposed to be a frozen and unchanging format.
And if we change it, anything that accepts it is automatically broken,
which is a very bad thing.

On 10 July 2012 20:55, Borislav Iordanov <borislav.iordanov@...>wrote:

> **
>
>
> On Tue, Jul 10, 2012 at 3:35 PM, Andrew Faulds <ajfweb@...>
> wrote:
> > I don't think this is a good idea. One of the best things, if not the
> best,
> > about JSON is the lack of a version number. The standard is frozen and
> will
> > never change, and because of that there is only one thing called JSON,
> and
> > everything that supports "JSON" today will support it tommorow, too.
>
> That's a valid argument, but is it such a big deal given that anything
> in software evolves and it's just natural to deal with versions?
>
> His proposition 1 and 2 are something I'm sure many would be happy
> with. One of the main virtues of JSON, to be easier to read and write
> by humans, is hurt by quotes requirement in names and the inability to
> use single quotes for strings. And there are parsers already that
> support those so the "standard" is often not strictly respected
> anyway.
>
>
> > Also, you haven't added omitting quotes round key names, and you've
> > introduced features JavaScript doesn't have, so I dislike it for that
> > reason anyway.
> >
> > On 10 July 2012 20:32, johnnys <marler8997@...> wrote:
> >
> >> **
>
> >>
> >>
> >> I've published a web page with some propositions to modify JSON at
> >> http://json.marler.info <http://json.marler.info>
> >> I wanted to post this so I could see what people think of these
> >> propositions. Any comments/suggestions/criticism are welcome.
> >>
> >> [Non-text portions of this message have been removed]
> >>
> >>
> >>
> >
> >
> >
> > --
> > Andrew Faulds (AJF)
> > http://ajf.me/
> >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>
> --
> http://www.kobrix.com, http://kobrix.blogspot.com,
> http://sharegov.blogspot.com, http://ilovefencing.com
>
> "Damn! The world is big!"
>
> -- Heleni Daly
>
>
>



--
Andrew Faulds (AJF)
http://ajf.me/


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

On Tue, Jul 10, 2012 at 12:55 PM, Borislav Iordanov
<borislav.iordanov@...> wrote:
> On Tue, Jul 10, 2012 at 3:35 PM, Andrew Faulds <ajfweb@...> wrote:
>> I don't think this is a good idea. One of the best things, if not the best,
>> about JSON is the lack of a version number. The standard is frozen and will
>> never change, and because of that there is only one thing called JSON, and
>> everything that supports "JSON" today will support it tommorow, too.
>
> That's a valid argument, but is it such a big deal given that anything
> in software evolves and it's just natural to deal with versions?

For some perspective on this, one could consider fate of XML 1.1,
which actually does not have this issue -- versioning was fully
defined to allow such upgrade.
XML 1.1 has some other compatibility issues, but most importantly it
has not really been used extensively, and seems like a failure.

So another way to ask this is: would anyone bother using a modified
version of (textual) JSON externally?

-+ Tatu +-

Your propositions looks very clear. However, I think it is a bad idea to
change JSON. JSON definitely has weak points (such as no predefined
structure for a table), but changing the standard will break everything
there is, which is far worse.

your first and second proposition are just about making it more flexible to
*generate* JSON, at the cost of making *parsing* more complex and thus
slower. I don't think there really is a problem with having to use double
quotes anyway, and thus nothing to solve here. A third party JSON parser
may allow unquoted or single quoted keys, and internally change them to
double quotes, things like that.

You are right with your third proposition about storing tables more
efficiently, however, I would rather choose to define a table standard on
top of JSON instead of adjusting JSON itself. (see for example the Google's
DataTable
<https://developers.google.com/chart/interactive/docs/reference>format).


On Tue, Jul 10, 2012 at 9:32 PM, johnnys <marler8997@...>wrote:

> **
>
>
> I've published a web page with some propositions to modify JSON at
> http://json.marler.info <http://json.marler.info>
> I wanted to post this so I could see what people think of these
> propositions. Any comments/suggestions/criticism are welcome.
>
> [Non-text portions of this message have been removed]
>
>
>


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