W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2006

[whatwg] JSONRequest

From: Martin Atkins <mart@degeneration.co.uk>
Date: Mon, 20 Mar 2006 08:35:00 +0000
Message-ID: <441E6934.6040007@degeneration.co.uk>
Douglas Crockford wrote:
> I am proposing a new mechanism for doing data transport in Ajax/Comet
> applications. It is called JSONRequest. It is a minimal communications
> facility that can be exempted from the Same Origin Policy.
> 
> You can read about it here: http://json.org/JSONRequest.html

This proposal seems to have a similar purpose to my (much less complete
and detailed) proposal here:

<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-February/005848.html>

The main differences that I see are:
* My proposal deals in interfaces rather than in data. It's possible to
implement a data source completely client-side, or (since the
instantiated object runs in the context of the remote site) provide a
restricted wrapper around XMLHttpRequest on the remote site.
* My proposal primarily lives within the client, while yours is to do
with clients talking to servers.

The thinking behind my propsal was based on the practice of "data
hiding" in OO languages; rather than exposing the data directly, just
expose an interface to the data. You can then change how it all works
later as long as the interface remains consistant.

One thing my proposal is lacking is a way to limit/alter responses based
on the caller. However, I think this could be achieved by adding an
object to the global scope of the remote script that contains
information about the caller such as hostname. This would be provided by
the UA and so is presumably trusted. (as much as the user trusts his UA.)

I'm aware that my proposal may also have some troubles when used under
other languages such as VBScript. It really needs a more
XMLHttpRequest-like API with event-based callbacks in order to be
portable. All that stuff can be figured out; I'm just throwing the idea
out there for now.
Received on Monday, 20 March 2006 00:35:00 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:45 UTC