There have been many requests for JSON t-shirts.
So I have made a couple of designs available at
http://www.zazzle.com/douglascrockford/products

Douglas, can I put my name in your Business Card? :D

Btw, specially the gray scale one looks really good, congrats.

Regards

P.S. do you sell outside USA as well? I did not check everything, cheers

On Thu, Oct 1, 2009 at 1:37 PM, Douglas Crockford <douglas@...>wrote:

>
>
> There have been many requests for JSON t-shirts.
> So I have made a couple of designs available at
> http://www.zazzle.com/douglascrockford/products
>
>
>


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

Hi all,
JSwoof tiny has finally been released. For those of you who do not want to be
tied into the FLEX framework. Or have size limitations to deal with.

It is a fraction of the size of its bigger brother JSwoof, but retains all of
its speed. As it is built using JSwoof's parsing core.

It does however come with some minor limitations like it will not be able to
serialize ArrayCollections as these are part of the main FLEX framework.

As usual you can download it at: http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike

Hi all,

Over at the JSON-RPC group I announced a new JSON related project [1] so I'll
give just a short overview here.

Pmrpc is a inter-window cross-domain remote procedure call JavaScript library
based on JSON-RPC [2] and the HTML5 postMessage API [3]. The library provides a
simple API for exposing and calling procedures from windows or iFrames on
different domains, without being subject to the same-origin policy. Pmrpc also
provides several advanced features: callbacks similar to AJAX calls, ACL-based
access control, asynchronous procedure support and fault-tolerance via retries.

For more information please visit the project homepage -
http://code.google.com/p/pmrpc/. Feedback is appreciated. :)

Thanks,
Ivan

[1]
http://groups.google.com/group/json-rpc/browse_thread/thread/c72e5a4a013957f4#
[2] http://groups.google.com/group/json-rpc/web/json-rpc-1-2-proposal
[3] http://www.w3.org/html/wg/html5/#crossDocumentMessages

Jansson v1.0.4 is out. This is a bugfix release in the 1.0 release series.

Changes since v1.0.3:

* Relax Autoconf version requirement to 2.59
* Make Jansson compile on platforms where plain char is unsigned
* Fix API tests for object

Download source: http://www.digip.org/jansson/releases/jansson-1.0.4.tar.bz2
View documentation: http://www.digip.org/jansson/doc/1.0/
Changelog: http://www.digip.org/jansson/releases/CHANGES


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
petri@...

I'm proud to announce that MJSON v1.2 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 C, which
means that it may run in any platform which is targeted by C compiler.

This release focuses on stability and offers a hand full of clean-ups bug fixes
and marks the start of the development of the v2.0 release, a complete rewrite
which will focus on improving the library's already impressive efficiency and
speed.


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

Rui Maciel

Jansson v1.1 is out. This release contains many new features and some
bugfixes, and retains API compatibility with the 1.0 series.

Changes since v1.0.4:

* API additions and improvements:
   - Extend array and object APIs
   - Add functions to modify integer, real and string values
   - Improve argument validation
   - Use unsigned int instead of uint32_t for encoding flags
* Enhance documentation
   - Add getting started guide and tutorial
   - Fix some typos
   - General clarifications and cleanup
* Check for integer and real overflows and underflows in decoder
* Make singleton values thread-safe (true, false and null)
* Enhance circular reference handling
* Don't define -std=c99 in AM_CFLAGS
* Add C++ guards to jansson.h
* Minor performance and portability improvements
* Expand test coverage

Download source: http://www.digip.org/jansson/releases/jansson-1.1.tar.bz2
View documentation: http://www.digip.org/jansson/doc/1.1/
Changelog: http://www.digip.org/jansson/releases/CHANGES


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
petri@...

Jswoof version 1.10 has been released. You can grab the zip from the
jswoof website as usual.

http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike.

Jansson v1.1.1 is out. This release only fixes a few packaging
issues with v1.1.

Changes since v1.1:

* All documentation files were not distributed with v1.1; build
   documentation in make distcheck to prevent this in the future
* Fix v1.1 release date in CHANGES

Download source: http://www.digip.org/jansson/releases/jansson-1.1.1.tar.gz
View documentation: http://www.digip.org/jansson/doc/1.1/
Changelog: http://www.digip.org/jansson/releases/CHANGES


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
petri@...

Hi all,

Jswoof-Tiny Version 1.01 has been released. I have also fixed the zip
folder for version 1.00 as it had gotten corrupted somehow.

As usual you can download it at: http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike

Hi folks,

mod_ndb 1.1 is now available at http://code.google.com/p/mod-ndb

mod_ndb is an interface to MySQL Cluster that runs inside an apache
web server.  It does not use MySQL servers, but communicates directly
with cluster data nodes using the low-level NDB API.

This version contains built-in support for the server side of Doug's
JSONRequest proposal (http://www.json.org/JSONRequest.html).  It also
can use JSON in general as an input format for HTTP requests and an
output format for database responses.

JD

Hello everyone,

Are any of you still supporting legacy ASP Classic systems? If so you
maybe interested in json2.asp (originally called json4asp).  It's a
slight modification to json2.js that allows it to be run on the server
and called from ASP pages written in VBScript.

You can read more at
http://tforster.wik.is/ASP_Classic_Practices_For_The_21st_Century/JSON4A\
SP
<http://tforster.wik.is/ASP_Classic_Practices_For_The_21st_Century/JSON4\
ASP>

Troy



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

Jansson v1.1.2 is out. This is a bug fix release in the 1.1 release
series.

Changes since v1.1.1:

* Fix a bug where an error message was not produced if the input file
   could not be opened in json_load_file()
* Fix an assertion failure in decoder caused by a minus sign without a
   digit after it
* Remove an unneeded include for stdint.h in jansson.h

Download source: http://www.digip.org/jansson/releases/jansson-1.1.2.tar.gz
View documentation: http://www.digip.org/jansson/doc/1.1/
Changelog: http://www.digip.org/jansson/releases/CHANGES


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
petri@...

Hi JSON-fans

PL/JSON is a JSON-implementation written in PL/SQL for Oracle. Since no bugs has
been found in more than a month, I have changed the project status from beta to
stable. The version remains to be 0.8.4 though.

PL/JSON is a complete JSON-implementation with very few limitations. It also
features path-selection, so you can navigate/edit JSON-objects like you would do
in JavaScript. The API is quite comprehensive and documented through examples
and a reference guide.

The implementation got all the functionality I need, but if you want to put in
other useful features, then please join the project and submit your changes. You
could also just post your ideas in the open discussion forum:
https://sourceforge.net/projects/pljson/forums/forum/935365.

You can download a copy at http://sourceforge.net/projects/pljson. The license
is MIT.

/Jonas

For those interested, JSON Schema has been submitted as an Internet
Draft to the IETF:
http://tools.ietf.org/html/draft-zyp-json-schema-01

-- Kris Zyp SitePen (503) 806-1841 http://sitepen.com

Hi all,

The latest version of jswoof has finally gone live. But its far from an update
its a complete rewrite. enabling it to acheive speeds 3x faster than previous
builds.

It is also important to note for those of you switching from version 1.10 that
the getLastError() function has been removed. As errors are now handled using
exceptions. So with that in mind you can just plug the library in as normal no
biggie and remove and calls to getLastError.

As usual you can get the latest version of jswoof from:

http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike.

The server at JSON.org is getting hammered. It turns out that there are some
sites that are linking directly to json2.js instead of dispensing it from their
own servers. By far the heaviest impact is from onlinebootycall.com. My
intention was to provide the world with a free implementation, but the world can
buy its own bandwidth.

So I have added this line as the first line in the json2.js file:

alert('IMPORTANT: Remove this line from json2.js before deployment.');

It will not break anything, but it should help get a message to the
onlinebootycalls that you should not load code from strange third party servers.
It is not safe.

Any interest in moving your code to an account on Github? Might also help with
people's desire for versioned-versions of your various code currently hosted
directly on json.org. You could simply link to the project itself, or even the
raw file.
You could even go so far as to use embedded Gists (with syntax highlighting and
all) for your code samples.
Anyway, just a thought.

-Brian Lopez (author of yajl-ruby)

--- In json@yahoogroups.com, "Douglas Crockford" <douglas@...> wrote:
>
> The server at JSON.org is getting hammered. It turns out that there are some
sites that are linking directly to json2.js instead of dispensing it from their
own servers. By far the heaviest impact is from onlinebootycall.com. My
intention was to provide the world with a free implementation, but the world can
buy its own bandwidth.
>
> So I have added this line as the first line in the json2.js file:
>
> alert('IMPORTANT: Remove this line from json2.js before deployment.');
>
> It will not break anything, but it should help get a message to the
onlinebootycalls that you should not load code from strange third party servers.
It is not safe.
>

There is more information at
http://www.stevesouders.com/blog/2009/12/10/crockford-alert/ and
http://ajaxian.com/archives/doug-crockford-and-the-online-booty-call-saga

Hi All,

Jswoof tiny has now been re-built using the new jswoof v1.12 core library.

As usual you can get the jswoof from http://www.waynemike.co.uk/jswoof

Regards
Wayne IV Mike.

Douglas, I think this move was brilliant, but as I have twitted, I wonder
how many devs wrote a:

window.alert = function(){};

before including external resources, rather than get the real/original
message (also because alert is something only RyanAir and few others could
still use "in 2010")

In any case, specially for a problematic subject as JSON evaluation is, I
guess you should be proud about the fact that many people simply trust your
implementation.
Moreover, as somebody already said, I think it's more about having an
automatically updated version, rather than grab your server bandwidth.

I think your JSON implementation should be hosted with a "Donate" button in
some place able to use pre-gzipped/deflated/plain version via ETag, 304, and
every possible technique able to make it safer and usable everywhere, with
clear benefits provided by common browsers cache.

Best Regards

On Sun, Dec 13, 2009 at 1:00 AM, Douglas Crockford <douglas@...>wrote:

>
>
> There is more information at
> http://www.stevesouders.com/blog/2009/12/10/crockford-alert/ and
> http://ajaxian.com/archives/doug-crockford-and-the-online-booty-call-saga
>
>
>


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

--- In json@yahoogroups.com, Andrea Giammarchi <andrea.giammarchi@...> wrote:
>
> Douglas, I think this move was brilliant, but as I have twitted, I
> wonder how many devs wrote a:
>
> window.alert = function(){};
>
> before including external resources, rather than get the real/original
> message

The point I was making was that if you care about reliability, security, and
performance, then you shouldn't load scripts directly from third party servers.
Are you suggesting that it is ok if you stub out alert first?

2009/12/14 Douglas Crockford <douglas@...>
>
> --- In json@yahoogroups.com, Andrea Giammarchi <andrea.giammarchi@...> wrote:
> >
> > Douglas, I think this move was brilliant, but as I have twitted, I
> > wonder how many devs wrote a:
> >
> > window.alert = function(){};
> >
> > before including external resources, rather than get the real/original
> > message
>
> The point I was making was that if you care about reliability, security, and
performance, then you shouldn't load scripts directly from third party servers.
Are you suggesting that it is ok if you stub out alert first?

I think he's suggesting that the people who need to get the point may
not actually get it - they'll just work around it with no idea why you
put it in there.

Just to underline another thing:

On Sun, Dec 13, 2009 at 6:38 PM, Douglas Crockford <douglas@...>wrote:

>
> The point I was making was that if you care about reliability, security,
> and performance
>
>
reliability ... they are including the de facto official JSON library for
JavaScript
security ... they trust your implementation and they trust the fact you keep
updating it
performances ... they are using a potentially "common used external
resource" so if the browser cached already that version performances will be
better for every website that includes it plus they are saving bandwidth.

As you can see somebody could think that your points ARE the reason they
included JSON via the direct source, rather than their local copy
potentially non updated and served even if almost every browser has stored
somewhere exactly the same library.

So, finally, I would think about a proper specific server or an official
repository Github style so that people than use the raw minified and gzipped
version with the 304 response, but if you think nobody should ever include
external scripts, you should tell us why we all have YUI configurator
scripts, google adsense/analytic files, etc etc.

Regards


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

If you go in YUI 3 Configurator the Result page provides a script to copy
and paste to include remotely the library.
http://developer.yahoo.com/yui/3/configurator/

If you go in Google Ajax libraries you will find external URIs to use third
part hosts as trusted safe and secure host with updated libraries.
http://code.google.com/apis/ajaxlibs/documentation/#AjaxLibraries

If you are using dojo library you probably know about AOL:
http://dev.aol.com/dojo

What am I saying is that we are not everybody under https and we trust, for
whatever reason, some external domain.
Not everybody could have followed the "alert story", I can already imagine
developers called 6am in the morning about an alert in the website that does
not use alerts at all.
These devs could have quickly solved the problem nullifying the alert
without caring about why the alert was there and, in the worst case
scenario, blaming you to have forgot an alert inside your library and
feeling cool to have solved an unexpected alert problem forever (so try with
prompt or confirm ...)

Since the message as is could sound more like you were testing something and
you forgot an alert, I would rather change the alert message with a link
that points WHY there is an alert.

I totally agree with you and it could often be about developers laziness (in
YUI case they did not use the php loader, etc etc) but at the same time:

  1 - every website could benefit about common external resources thanks to
distributed cache for common libaries
  2 - this message is not perfectly clear since somebody, YUI! itself, is
suggesting external resources while you, a Yahoo! engineer, are saying that
this is so bad that anybody should avoid this technique

Do you see what I mean?

Regards


On Sun, Dec 13, 2009 at 6:38 PM, Douglas Crockford <douglas@...>wrote:

>
>
> --- In json@yahoogroups.com <json%40yahoogroups.com>, Andrea Giammarchi
> <andrea.giammarchi@...> wrote:
> >
> > Douglas, I think this move was brilliant, but as I have twitted, I
> > wonder how many devs wrote a:
> >
> > window.alert = function(){};
> >
> > before including external resources, rather than get the real/original
> > message
>
> The point I was making was that if you care about reliability, security,
> and performance, then you shouldn't load scripts directly from third party
> servers. Are you suggesting that it is ok if you stub out alert first?
>
>
>


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

On 12/13/2009 09:34 PM, Andrea Giammarchi wrote:
>
> Just to underline another thing:
>
> On Sun, Dec 13, 2009 at 6:38 PM, Douglas Crockford
> <douglas@... <mailto:douglas%40crockford.com>>wrote:
>
> >
> > The point I was making was that if you care about reliability, security,
> > and performance
> >
> >
> reliability ... they are including the de facto official JSON library for
> JavaScript
> security ... they trust your implementation and they trust the fact
> you keep
> updating it
> performances ... they are using a potentially "common used external
> resource" so if the browser cached already that version performances
> will be
> better for every website that includes it plus they are saving bandwidth.
>
> As you can see somebody could think that your points ARE the reason they
> included JSON via the direct source, rather than their local copy
> potentially non updated and served even if almost every browser has stored
> somewhere exactly the same library.
>

Hi Andrea,

I think you are forgetting that the (current) json.org website is
probably just a shared-hosting
account.

So that probably means it's not as reliable as something Google or Yahoo
might do for some of the js-libraries.

Performance-wise it would be really bad if everyone started hotlinking
to just that one (or maybe 2 or 3) server(s) as well.

Security-wise, something like the CDN-like setup Google and Yahoo are
doing have a lot of save-gaurds,
like monitoring tools and employees for file-changes. Seperate dedicated
datacenters or atleast 'cages' of
dedicated 19"-racks of servers. And not to forget procedures.

While I do think getting automatic updates of json[2].js would be really
interresting, because it's a very
security-sensitive library.

So in the current situation, it's a really bad idea.

>
> So, finally, I would think about a proper specific server or an official
> repository Github style so that people than use the raw minified and
> gzipped
> version with the 304 response, but if you think nobody should ever include
> external scripts, you should tell us why we all have YUI configurator
> scripts, google adsense/analytic files, etc etc.
>

Yes, I think some people would love to see Yahoo add json[2].js to their
list of js-libraries
they are already hosting on their own CDN (I think Google has a whole
list of libraries).

But maybe Mr. Crockford does not want his personal project to be tied to
his (current)
employer or Google. I don't know their, could be many reasons.

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

i noticed that this works with the native JSON object in FF3.5.5

  JSON.parse(["true"])

but with the json2.js this throws an error.

which one is the intended behaviour?

greetings
  simon

I guess that json2.js is supposed to work on Json-Text and not java arrays with
json-text.

You could do this instead:

JSON.parse('["true"]');


--- In json@yahoogroups.com, "nostalgiker" <nostalgiker@...> wrote:
>
> i noticed that this works with the native JSON object in FF3.5.5
>
>  JSON.parse(["true"])
>
> but with the json2.js this throws an error.
>
> which one is the intended behaviour?
>
> greetings
>  simon
>

okay, i figured that out ;) bwt it's a plain javascript array, not java.

but i was actually wondering why IE8 and FF3.5+ allow this with their native
JSON objects - passing an array with one element to parse()

so does the jquery.json pluggin - which is unmaintained. that is why i switched
to json2... where i noticed that it doesnt support this, but everybody else
seems to.

JavaScript provides automatic type conversions on a lot of action

So if you do

var foo = ["bar"] + " baz";

["bar"] will be converted into "bar" and you'll have foo === "bar baz"

you can also see that in JavaScript ["foo"] == "foo"

and String["foo"]) === "foo"

Then when you send an array to a function expecting a string, and this function
doesn't check the type of the parameter ( or force it to string), you'll have
what you get


Le 17 déc. 2009 à 11:45, nostalgiker a écrit :



okay, i figured that out ;) bwt it's a plain javascript array, not java.

but i was actually wondering why IE8 and FF3.5+ allow this with their native
JSON objects - passing an array with one element to parse()

so does the jquery.json pluggin - which is unmaintained. that is why i switched
to json2... where i noticed that it doesnt support this, but everybody else
seems to.






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