Hm.

Personally, I wouldn't go this way; you're making a bet that the
overhead of setting up SSL/TLS is less than that of working
synchronously. If you're just POSTing stuff to the server, combining
several things into one request format may be the way to go.

That having been said -- if you are going to use https, you'll need to
have an API available that guarantees to give you a single connection
back. XHR doesn't do that.

I totally agree that pipelining is useful, and reducing latency is a
good goal. It's just that the proper place to fix this sort of thing
is lower in the stack, not higher.

Cheers,


On 01/01/2008, at 7:24 AM, Tyler Close wrote:

> Hi Mark,
>
> I think message ordering and pipelining are really useful features, so
> I'ld like to kick this around some more to see if there's something
> that could work. For example, I've seen some web applications that
> implement their own request boxcarring to compensate for the lack of
> pipelining. At this point, they are basically tunneling their own
> protocol through HTTP and so not getting many of the benefits of HTTP,
> such as caching.
>
> On Dec 18, 2007 9:06 PM, Mark Nottingham <mnot@...> wrote:
> > There are several aspects, but if you have an outstanding request
> on a
> > connection, and another request is queued, deciding whether it's
> more
> > efficient to pipeline or to open a new connection (or, to wait for
> > the other connection to clear) isn't always a simple thing to do. If
> > the outstanding request takes a long time to process (either because
> > the response is very large, or because it takes a lot of server-side
> > processing time), it may be better to use your other connection.
>
> Seems like this logic is something that should be expressed by the end
> client. So if the client issued requests like:
>
> JSONRequest.post(...);
> JSONRequest.post(...);
>
> it's saying there is no expected ordering and the browser should use
> separate connections if possible. Whereas if the client issued
> requests like:
>
> var c = JSONRequest.ordered();
> c.post(...);
> c.post(...);
>
> it's saying these requests must be ordered and the browser should
> pipeline over a single connection if possible.
>
> > > How about this: If there is no HTTP proxy, pipeline requests;
> > > otherwise, send the requests one at a time. So if the client asked
> > > that requests be ordered, this is guaranteed and performance is
> best
> > > effort. If the client doesn't care about ordering, but wants best
> > > performance, then it uses separately instantiated JSONRequest
> objects.
> > > Sound good?
> > >
> > You don't always know whether there's an intermediary there;
> > interception proxies (aka "transparent proxies") and HTTP
> accelerators
> > aren't apparent to the client.
>
> OK then, SSL to the rescue. For the case where the client asks that
> requests be sent in order:
>
> 1. If its an HTTPS connection, open a single connection and pipeline
> the requests.
> 2. Otherwise, open a single connection and send requests
> synchronously.
>
> For requests that don't use the ordered request API, they can be sent
> as they currently are, over multiple connections.
>
> This seems like a small amount of complexity to add, while gaining the
> benefits of message ordering and pipelining when making secure
> web-applications.
>
> I suppose there could be some server-side infrastructure that again
> "helps" the developer by re-ordering requests, but the web-application
> developer is presumably in a better position to do something about
> this. Are there any other gremlins?
>
> Thanks,
> --Tyler
>
> --
> Use web-keys for RESTful access-control:
> http://waterken.sourceforge.net/
>
> Name your trusted sites to distinguish them from phishing sites.
> https://addons.mozilla.org/firefox/957/
>
>

--
Mark Nottingham       mnot@...

On Jan 2, 2008 11:15 AM, Mark Nottingham <mnot@...> wrote:
>
>
>
>
>
>
> Hm.
>
>  Personally, I wouldn't go this way; you're making a bet that the
>  overhead of setting up SSL/TLS is less than that of working
>  synchronously. If you're just POSTing stuff to the server, combining
>  several things into one request format may be the way to go.
>
>  That having been said -- if you are going to use https, you'll need to
>  have an API available that guarantees to give you a single connection
>  back. XHR doesn't do that.
>
>  I totally agree that pipelining is useful, and reducing latency is a
>  good goal. It's just that the proper place to fix this sort of thing
>  is lower in the stack, not higher.
>
>  Cheers,
>
>  On 01/01/2008, at 7:24 AM, Tyler Close wrote:
>
>  > Hi Mark,
>  >
>  > I think message ordering and pipelining are really useful features, so
>  > I'ld like to kick this around some more to see if there's something
>  > that could work. For example, I've seen some web applications that
>  > implement their own request boxcarring to compensate for the lack of
>  > pipelining. At this point, they are basically tunneling their own
>  > protocol through HTTP and so not getting many of the benefits of HTTP,
>  > such as caching.
>  >
>  > On Dec 18, 2007 9:06 PM, Mark Nottingham <mnot@...> wrote:
>  > > There are several aspects, but if you have an outstanding request
>  > on a
>  > > connection, and another request is queued, deciding whether it's
>  > more
>  > > efficient to pipeline or to open a new connection (or, to wait for
>  > > the other connection to clear) isn't always a simple thing to do. If
>  > > the outstanding request takes a long time to process (either because
>  > > the response is very large, or because it takes a lot of server-side
>  > > processing time), it may be better to use your other connection.
>  >
>  > Seems like this logic is something that should be expressed by the end
>  > client. So if the client issued requests like:
>  >
>  > JSONRequest.post(...);
>  > JSONRequest.post(...);
>  >
>  > it's saying there is no expected ordering and the browser should use
>  > separate connections if possible. Whereas if the client issued
>  > requests like:
>  >
>  > var c = JSONRequest.ordered();
>  > c.post(...);
>  > c.post(...);
>  >
>  > it's saying these requests must be ordered and the browser should
>  > pipeline over a single connection if possible.
>  >

Not all browsers support pipelining. Opera has it enabled, Firefox has
it disabled by default; The browser must be able to handle it
transparently to the JS app; Synchronous requests with browser-side
polling may benefit from pipelining; Pipelining effects are good only
for small-sized requests; So the browser should determine when to
pipeline or not (depending on immediately receiving the response
content-length)

>  > > > How about this: If there is no HTTP proxy, pipeline requests;
>  > > > otherwise, send the requests one at a time. So if the client asked
>  > > > that requests be ordered, this is guaranteed and performance is
>  > best
>  > > > effort. If the client doesn't care about ordering, but wants best
>  > > > performance, then it uses separately instantiated JSONRequest
>  > objects.
>  > > > Sound good?
>  > > >
>  > > You don't always know whether there's an intermediary there;
>  > > interception proxies (aka "transparent proxies") and HTTP
>  > accelerators
>  > > aren't apparent to the client.
>  >
>  > OK then, SSL to the rescue. For the case where the client asks that
>  > requests be sent in order:
>  >
>  > 1. If its an HTTPS connection, open a single connection and pipeline
>  > the requests.
>  > 2. Otherwise, open a single connection and send requests
>  > synchronously.
>  >
>  > For requests that don't use the ordered request API, they can be sent
>  > as they currently are, over multiple connections.
>  >
>  > This seems like a small amount of complexity to add, while gaining the
>  > benefits of message ordering and pipelining when making secure
>  > web-applications.
>  >
>  > I suppose there could be some server-side infrastructure that again
>  > "helps" the developer by re-ordering requests, but the web-application
>  > developer is presumably in a better position to do something about
>  > this. Are there any other gremlins?
>  >
>  > Thanks,
>  > --Tyler
>  >
>  > --
>  > Use web-keys for RESTful access-control:
>  > http://waterken.sourceforge.net/
>  >
>  > Name your trusted sites to distinguish them from phishing sites.
>  > https://addons.mozilla.org/firefox/957/
>  >
>  >
>
>  --
>  Mark Nottingham mnot@...
>
>



--
Karthik
http://guilt.bafsoft.net

Hi,
JON Tools's subprojects had been released.
JON Tools is composed by:
SAJ - Simple API for JSON ==> is an event parser of json stream with
schema validation support
DOMJson ==> is a DOM rapresentation of json stream. This uses SAJ for
parsing.

Hi,
has been released the release 1.1.0 of DOMJson.
New features are:
* json schema validation
* JSONPath support

Hi all,

I've lately released a very minimalistic JSON parser for C++.

   => http://blog.beef.de/2008/01/04/tinyjson/

Why another C++ parser?

While I really like the puristic and lightweight approach of the JSON
format, the C++ libraries on JSON.org feel a bit to "heavy weighted"
to me. Mainly the introduction of an own object model class hierarchy
(why does everyone re-invent the variant class if there is a de-facto
standard as Boost.Any?), and the use of own exception handling classes
made it quite hard to integrate one of the libs into my already
existing project! Furthermore, some classes where not type-safe or
lacked the support of Unicode characters - which is crucial in my case!

So I implemented an own JSON parser (only reading, _not_ writing) that
uses Boost.Spirit for parsing and Boost.Any for the variant type. The
light-weighted code significantly simplifies the migration of JSON in
existing projects.

Any feedback is welcome!

--Thomas Jansen

Hi everyone,

I'd like to share JSON parser, an extension of the JSON_checker code
provided by http://www.json.org/ .

The code is at http://fara.cs.uni-potsdam.de/~jsg/json_parser/ .

I suppose the most notable things about JSON parser are (a) optional
support for C-style comments and (b) automatic decoding of UTF-16
(\uXXXX) & escaped characters (e.g. \\n) to UTF-8.

Regards,
Jean Gressmann
--
Programming is fun except for the problems.

FYI, last week I posted an update for JsonFx JsonSerializer.  Updates
include:

  - expanded JSON object serialization to include any IDictionary with
String keys
  - making DateTime serialization conform to ISO-8601
  - minor bug fixes

Check it out (as well as other open source tools) at:

     http://jsonfx.net/BuildTools/

Thanks,
Stephen

--- In json@yahoogroups.com, "Stephen M. McKamey" <jsonml@...> wrote:
>
> I've been using my C# JSON parser for about a year now as I've been
> building out a larger end-to-end Ajax framework.  Last week, I
released
> the JSON parser which the framework is built upon.
>
> The parser/serializer is written in C# and is intended to be as
easy to
> use as XML serialization in .NET.  It includes the option to
control
> serialization using attributes or implementing an interface.  It
has
> the ability to serialize and deserialize strongly-typed classes.
>
> Until the entire framework is available, I encourage you to try out
the
> parser:
>
>     http://jsonfx.net/BuildTools/
>
> Thanks,
> Stephen McKamey
>

http://lloydforge.org/projects/yajl

A ChangeLog is availabe on that site, and in the distribution.

enjoy,
lloyd

--
lloydh@... | appreciate value won the of
          http://docs.yahoo.com/info/values/

I'm very pleased to announce the release of jabsorb 1.2.2.

jabsorb is a simple and lightweight (yet quite powerful) Ajax/Web
2.0framework that allows you to call methods in a Java web application
from
JavaScript code running in a web browser as if they were local objects
residing directly in the browser.

The most important feature in the jabsorb 1.2.x release line is an extension
to the JSON-RPC protocol that allows passing of data structures with
circular and duplicate references.

With jabsorb 1.2.2 the json-rpc-client project has been combined with
jabsorb to include an additional Java client to the jabsorb server.  Special
thanks to Sasha Ovanskin for this immensely useful contribution.

Additionally, the jabsorb team has recently rolled out a whole new web site,
wiki and infrastructure at http://jabsorb.org

To download this release, visit http://jabsorb.org/Download
For general information on jabsorb, visit http://jabsorb.org
For discussion, questions or comments, visit
http://groups.google.com/group/jabsorb-user

Cheers!
Arthur Blake


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

On Jan 16, 2008 4:19 PM, Arthur Blake <arthur.blake@...> wrote:

> I'm very pleased to announce the release of jabsorb 1.2.2.
>
> jabsorb is a simple and lightweight (yet quite powerful) Ajax/Web
> 2.0framework that allows you to call methods in a Java web application
> from
> JavaScript code running in a web browser as if they were local objects
> residing directly in the browser.


That sounds a lot like DWR. Can you provide a brief comparison?

--
Martin Cooper


The most important feature in the jabsorb 1.2.x release line is an extension
> to the JSON-RPC protocol that allows passing of data structures with
> circular and duplicate references.
>
> With jabsorb 1.2.2 the json-rpc-client project has been combined with
> jabsorb to include an additional Java client to the jabsorb server.
>  Special
> thanks to Sasha Ovanskin for this immensely useful contribution.
>
> Additionally, the jabsorb team has recently rolled out a whole new web
> site,
> wiki and infrastructure at http://jabsorb.org
>
> To download this release, visit http://jabsorb.org/Download
> For general information on jabsorb, visit http://jabsorb.org
> For discussion, questions or comments, visit
> http://groups.google.com/group/jabsorb-user
>
> Cheers!
> Arthur Blake
>
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


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

>
> On Jan 16, 2008 11:07 PM, Martin Cooper <mfncooper@...> wrote:
> On Jan 16, 2008 4:19 PM, Arthur Blake
<arthur.blake@...<arthur.blake%40gmail.com>>
> wrote:
>
> > I'm very pleased to announce the release of jabsorb 1.2.2.
> >
> > jabsorb is a simple and lightweight (yet quite powerful) Ajax/Web
> > 2.0framework that allows you to call methods in a Java web application
> > from
> > JavaScript code running in a web browser as if they were local objects
> > residing directly in the browser.
>
> That sounds a lot like DWR. Can you provide a brief comparison?
>
> --
> Martin Cooper


I'm not a DWR expert, but from what I understand, both libraries fulfill the
same basic purposes.

The main difference that I've always touted is:

jabsorb is based on JSON-RPC standard (although with new circular references
support, standard JSON-RPC is extended)
DWR uses it's own inherent protocol, but new JSON features are being added.
DWR also has some built in support for reverse ajax.  This can be done with
jabsorb too, but it's not as integrated like it is with DWR.
DWR appears to have a larger code base and more bells and whistles, while
jabsorb is a bit lighter and simpler.

So it appears that the libraries are currently converging in their feature
sets, somewhat.

Both jabsorb and DWR have been been around for quite awhile.  jabsorb was
formerly known as JSON-RPC-Java.  (It was originally forked off of
JSON-RPC-Java, but then the parent project joined jabsorb to form a unified
project, yet retaining the jabsorb name.)

It would be nice to hear some pros and cons from anyone who has used both
libraries extensively.


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

I have created four LotusScript classes for handling JSON.  The main
classes are JSONReader and JSONWriter.  There are also two wrapper
classes for representing the data objects in LotusScript:  JSONArray and
JSONObject.

The JSONReader class accepts a string of JSON formatted text and
converts it into LotusScript objects using JSONArray and/or JSONObject.
These two wrapper classes also have a method to convert the object back
to a JSON string.  The JSONWriter class accepts any data note
(NotesDocument, NotesDocumentCollection, NotesView, NotesViewEntry,
NotesViewEntryCollection) and outputs the data in JSON format.  You can
also use JSONWriter to build a JSON string on the fly using the
following methods:  BeginObject, BeginArray, AppendValue, etc.

The Notes database containing the classes, documentation, and examples
can be downloaded at the following URL:
http://download.snapps.com/QuickPlace/demoplace/Main.nsf/h_Toc/0BBA7F4B5\
3DEA55E862573DB00647CF6/?OpenDocument
<http://download.snapps.com/QuickPlace/demoplace/Main.nsf/h_Toc/0BBA7F4B\
53DEA55E862573DB00647CF6/?OpenDocument>



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

Hey guys,

I've written a little JSON validator / reformatter service that I'm
hoping is useful for everyone. I use it constantly myself, so I figure
others might be interested also. I've noticed that many people don't
use strictly valid JSON.

It's at http://www.jsonlint.com
   <http://www.jsonlint.com>
In particular, I'd love any FEEDBACK you'd have on it.

Thanks all.

-Umbrae




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

FYI, an update for JsonFx JsonSerializer is available.  Round-trip
support is improved for strongly typed objects.

     http://jsonfx.net/BuildTools/

Features:

- Functions like XML Serialization in .NET, including the optional
ability to control serialization via attributes/interfaces

- Serializes and deserializes IDictionary<String, T> and IDictionary
with String keys directly as a JSON object

- Serializes and deserializes List<T>, ArrayList, LinkedList<T>,
Queue<T> and many other IEnumerable types directly as JSON arrays

- Serializes and deserializes DateTime, Enum, Nullable<T>, Guid and
other common .NET Types directly as JSON primitives

- Serializes and deserializes strongly-typed classes (similarly to
XML Serialization in .NET)

Is anyone aware of a JSON parser written in JavaScript that doesn't use
the eval() function at all, but instead just does the entire parsing
using regular expressions and string functions?

I'm curious because I have a situation where I want to parse JSON
myself, but my code doesn't have access to eval() for security reasons
(it's being run on a Facebook profile page).

Thanks,

Jesse

The Jayrock project has a json.js version that supports both. A "safe eval" as
well as a pure JavaScript JSON parser available via the "parse" method.
See http://svn.berlios.de/wsvn/jayrock/trunk/www/json.js

The parse method actually comes from one of the original json.js versions that
used to be available from http://json.org before it switched to an
implementation using regex-verification followed by a native eval. The parser is
more accepting of JavaScript's object notation than what's strictly allowed as
JSON text as per RFC 4627. For example, it supports slash-slash and /*...*/
style of comments. It is nonetheless a conforming parser. From the header
comment...

     JSON.parse(text) takes a JSON text and produces a JavaScript value.
     It will throw SyntaxError if there is an error in parsing the JSON
     text. This method is fully JavaScript-based and therefore can be
     several magnitudes slower than JSON.eval. However, it is also more
     permissive than JSON.eval. For example, JSON.parse permits use of
     JavaScript-style comments in JSON text.

     JSON.eval(text) takes a JSON text and produces a JavaScript value.
     It will throw SyntaxError if there is an error in parsing the JSON
     text. JSON.eval is much faster (as it internally relies on the
     JavaScript eval method after making safety checks) and stricter in
     complaince to JSON text.

HTH,
Atif

From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of Jesse
Skinner
Sent: Thursday, February 07, 2008 12:13 PM
To: json@yahoogroups.com
Subject: [json] JavaScript JSON parser without eval()


Is anyone aware of a JSON parser written in JavaScript that doesn't use
the eval() function at all, but instead just does the entire parsing
using regular expressions and string functions?

I'm curious because I have a situation where I want to parse JSON
myself, but my code doesn't have access to eval() for security reasons
(it's being run on a Facebook profile page).

Thanks,

Jesse



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

Yes.

Doug Crockford's ORIGINAL json parser {circa 2005 or so} did NOT use
the eval function -- it was a strict tokenizer / regex mechanism both
for parsing a JSON string and for stringifying a JSON Object....

I did NOT see the original on json.org -- perhaps Doug or someone
else has an archived copy laying around --

I have a modified copy I would be willing to share if you ask
nicely...

Greg



--- In json@yahoogroups.com, Jesse Skinner <jesse@...> wrote:
>
> Is anyone aware of a JSON parser written in JavaScript that doesn't
use
> the eval() function at all, but instead just does the entire
parsing
> using regular expressions and string functions?
>
> I'm curious because I have a situation where I want to parse JSON
> myself, but my code doesn't have access to eval() for security
reasons
> (it's being run on a Facebook profile page).
>
> Thanks,
>
> Jesse
>

json_parser.js is a JavaScript JSON parser that does not use eval. It
can be used in environments in which Regexp or eval is not available.

http://json.org/json_parser.js

Hi

I have released a beta version of my Json.NET library. This new
version  adds LINQ to JSON.

You can find out more about LINQ to JSON here:
http://james.newtonking.com/archive/2008/02/11/linq-to-json-beta.aspx

And Json.NET in general here:
http://james.newtonking.com/projects/json-net.aspx


~ James

Hi All,



I have just started looking into using JSON as a way to send data
between the client and server.  I would like to know which JSON to use?
I see json.org, json-lib, json-RPC and others.



Any advice would be appreciated.





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

Hi all,

I would like to announce the release of my JSON Serialization library
for C#.  The project is called JsonExSerializer can be found at:

    http://jsonexserializer.googlecode.com

Built primarily for Serialization/Deserialization, it is unique in
that it uses a small set of extensions to the JSON format to store
Type information and references.  These extensions allow you to
deserialize objects exactly as you serialized them.  These extensions
can also be suppressed when being used in an environment that doesn't
support them.

Thank you,
Ted Elliott

Hi all,

I've developed a 1-1 (reversible) mapping from JSON into XML in order to
be able to process JSON from XQuery. The current CVS version of XQilla
supports the parsing of JSON into XML and back, and the next release
will include that support.

http://snelson.org.uk/archives/2008/02/parsing_json_in.php

I'd welcome your comments and feedback,

John

--
John Snelson, Oracle Corporation            http://snelson.org.uk/john
Berkeley DB XML:        http://www.oracle.com/database/berkeley-db/xml
XQilla:                                  http://xqilla.sourceforge.net

Hi,

Douglas Crockford asked me to report the problem on this yahoo group.

I am using CLDC 1.1 and MIDP 2.1. If the json.me package was meant to support
this platform, then it will not. Since the class JSONStringer uses
java.io.StringWriter which does not exist in any of the above platforms. The
good part is that JSONStringer is not used by other classes in the same package
and hence can be excluded and the JSON functionality can still be used.

If the package targets CDC devices, then maybe StringWriter exists but I cannot
confirm that. A google on CDC platforms can give some answer.

Thanks
Himanshu


---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

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

It will work in CDC - Personal Profile

http://java.sun.com/javame/reference/apis/jsr216/

Maybe its better, if we use a ported version of this class so it can work across
all J2ME platforms. Also, if this class is ported (java.io.StringWriter), please
do not give it a name containing "java..." otherwise users will need to do
obfuscation.

Himanshu

Himanshu Ranavat <himanshu_ranavat@...> wrote:
Hi,

  Douglas Crockford asked me to report the problem on this yahoo group.

  I am using CLDC 1.1 and MIDP 2.1. If the json.me package was meant to support
this platform, then it will not. Since the class JSONStringer uses
java.io.StringWriter which does not exist in any of the above platforms. The
good part is that JSONStringer is not used by other classes in the same package
and hence can be excluded and the JSON functionality can still be used.

  If the package targets CDC devices, then maybe StringWriter exists but I cannot
confirm that. A google on CDC platforms can give some answer.

  Thanks
  Himanshu

  ---------------------------------
  Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

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






---------------------------------
Never miss a thing.   Make Yahoo your homepage.

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

Hi Himanshu,

An update of the org.json.me library hosted at
https://meapplicationdevelopers.dev.java.net/mobileajax.html worked
around this issue by supplying its own minimal implementation of
StringWriter in the org.json.me package itself. This library has been
tested extensively on several CLDC/MIDP devices, including some very
low-end ones, so it should work with all current devices (although I
suspect most of the usage on devices has been on consuming json rather
than producing it).

Since the zipfile hosted at json.org is now known to have this bug, we
can either

1. update the zipfile with the latest source from the
meapplicationdevelopers project, or

2. replace the zipfile with a link to the meapplicationdevelopers
project (which does not provide zips, in order to accommodate a large
variety of devices with varying capabilities)

I can supply the updated zip, please let me know.

Thanks

On 02/25/2008 09:54 PM, Himanshu Ranavat wrote:
> Hi,
>
> Douglas Crockford asked me to report the problem on this yahoo group.
>
> I am using CLDC 1.1 and MIDP 2.1. If the json.me package was meant to support
this platform, then it will not. Since the class JSONStringer uses
java.io.StringWriter which does not exist in any of the above platforms. The
good part is that JSONStringer is not used by other classes in the same package
and hence can be excluded and the JSON functionality can still be used.
>
> If the package targets CDC devices, then maybe StringWriter exists but I
cannot confirm that. A google on CDC platforms can give some answer.
>
> Thanks
> Himanshu
>
>
> ---------------------------------
> Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>

Hi,

I do not have access to the ability to upload or make changes to json.org
website. However, my personal suggestion would be to take an updated zip file
from Akhil and upload it to the website. In addition to that there can also be a
link  to the project they are developing. I would leave this decision to those
who have control over what goes on json.org website

Thanks Akhil

Himanshu

Akhil Arora <akhil@...> wrote:                               Hi Himanshu,

  An update of the org.json.me library hosted at
  https://meapplicationdevelopers.dev.java.net/mobileajax.html worked
  around this issue by supplying its own minimal implementation of
  StringWriter in the org.json.me package itself. This library has been
  tested extensively on several CLDC/MIDP devices, including some very
  low-end ones, so it should work with all current devices (although I
  suspect most of the usage on devices has been on consuming json rather
  than producing it).

  Since the zipfile hosted at json.org is now known to have this bug, we
  can either

  1. update the zipfile with the latest source from the
  meapplicationdevelopers project, or

  2. replace the zipfile with a link to the meapplicationdevelopers
  project (which does not provide zips, in order to accommodate a large
  variety of devices with varying capabilities)

  I can supply the updated zip, please let me know.

  Thanks

  On 02/25/2008 09:54 PM, Himanshu Ranavat wrote:
  > Hi,
  >
  > Douglas Crockford asked me to report the problem on this yahoo group.
  >
  > I am using CLDC 1.1 and MIDP 2.1. If the json.me package was meant to support
this platform, then it will not. Since the class JSONStringer uses
java.io.StringWriter which does not exist in any of the above platforms. The
good part is that JSONStringer is not used by other classes in the same package
and hence can be excluded and the JSON functionality can still be used.
  >
  > If the package targets CDC devices, then maybe StringWriter exists but I
cannot confirm that. A google on CDC platforms can give some answer.
  >
  > Thanks
  > Himanshu
  >
  >
  > ---------------------------------
  > Looking for last minute shopping deals?  Find them fast with Yahoo! Search.
  >
  > [Non-text portions of this message have been removed]
  >
  >
  >
  >
  > Yahoo! Groups Links
  >
  >
  >






---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

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

> I do not have access to the ability to upload or make changes to
json.org website.

> I would leave this decision to those who have control over what goes
on json.org website

Send me a file of good stuff and I will put it on JSON.org.

Okay, let see if I can come up with something

Himanshu

Douglas Crockford <douglas@...> wrote:                               >
I do not have access to the ability to upload or make changes to
  json.org website.

  > I would leave this decision to those who have control over what goes
  on json.org website

  Send me a file of good stuff and I will put it on JSON.org.






---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

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

Support was added to the Java reference implementation for Apple's Old
Style ASCII Property Lists. It recognizes strings, arrays, and
dictionaries. It is significantly more pleasant to use than Apple's
XML Property Lists.

http://json.org/java/

I'm proud to announce that MJSON v0.8 has been released!

MJSON is Maciel's JSON parser, a small light-weight library that
handles documents written in the JSON markup language. It's written in
ISO C, which means that it may run wherever there is a C compiler.

MJSON can be found at:
http://sourceforge.net/projects/mjson


Rui Maciel