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

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]

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]

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.

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

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]

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.

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

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

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.

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.

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

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

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]