Hi Eric,
A few cases:
If one's server deals with moderate to large sized features, then cjson is
considerably quicker.
I did a quick test on a json string, where len(json) == 1000, and cjson is
a factor of 3+ times
faster.
Some platforms (such as the S60 platform) don't make it easy to compile your
own python C extensions, which makes jsonlib more attractiive.
One of my current projects invovles deploying to a Python app on a Nokia N95
- which , delivers location based services, it'd be nice if I could use
geojson on that without having to compile a version of simplejson for the
S60 platform, especially in prototyping phase.
That said, speed and platform choise are not my main motivation, there are
close to 5,000 downloads of cjson,
and jsonlib has 777 - so if any of these users end up in the game of gis, I
think it'd be nice for them not have force them to change to using
simplejson, or worse; re-implement geojsonlib.
Regardless of whether or not we allow for other json libraries,
I'm strongly in favour of removing geojsonlib.dump and geojsonlib.load for
reasons previously stated, and for renaming geojsonlib.dumps to
geojsonlib.encode and loads to geojsonlib.decode.
Any objections? I'd like this to be done before geojsonlib makes 1.0 so that
it has time to bed in.
Matt
2008/6/18 Eric Lemoine <[EMAIL PROTECTED]>:
> Hi. Stupid question: why allowing the use of other libraries than
> simplejson in the first place? Are there cases where simplejson
> would'nt meet one's needs? Thanks. Eric
>
> 2008/6/18, Matthew Russell <[EMAIL PROTECTED]>:
> > Hi,
> >
> > this is a proposal which Sean already +1'd in the recent "[Community]
> [Fwd:
> > [Geojson] GeoJSON 1.0 Released]" thread.
> >
> > The proposal is to remove the reliance on simplejson from geojsonlib (but
> > keeping simplejson as the default).
> >
> > I'n slight alteration to my previous api suggestion for the interface for
> > simplejson's peers,
> > I'd like to change the api from:
> >
> > geojsonlib.{dumps, dump, loads, load}
> >
> > to:
> >
> > json = geojsonlib.encode(obj, codec="geojsonlib.defaultcodec",
> *codec_args,
> > **codec_kwargs)
> > - where obj is any python object supporting the geointerface, or a
> mapping
> > - returns unicode or str
> >
> > obj = geojsonlib.decode(json, codec="geojsonlib.defaultcodec",
> *codec_args,
> > **codec_kwargs)
> >
> > - where 'json' is a unicode or str instance.
> > - reutrns a geojsonlib.GeoJSON instance or subclass thereof.
> >
> > The primary motivation for this is file encoding.
> > I'd like to keep the serialisation to file-like objects within the
> control
> > of the user at the I/O boundaries.
> > Removing the dump and load functions from geojsonlib would acheive this.
> > I also think the names encode and decode are better, since load and dumps
> > indicate serialization to disk.
> >
> > So, does anyone object if the api changes from:
> > geojsonlib.dumps -> geojson.encode
> > geojsonlib.loads -> geojson.decode
> > geojsonlib.dump -> file_like.write(geojsonlib.encode(obj))
> > geojsonlib.load -> geojsonlib.decode(file_like.read())
> >
> > ?
> >
> > Once this is implemented, simplejson will only be required in the default
> > case:
> >
> > .encode(obj), .decode(obj)
> >
> > and not if you want to use another JSON library, and have an adapter:
> >
> > e.g
> >
> > class CjsonEncoder:
> > def encode(self, obj):
> > ...
> >
> > .encode(obj, codec=CjsonEncoder)
> >
> > N.B:
> >
> > 'codec' can be a dotted path, or any namespace with a .encode or .decode
> > callable attribute as releveant.
> >
> > --
> > Cheers,
> > Matt
> >
> _______________________________________________
> Community mailing list
> [email protected]
> http://lists.gispython.org/mailman/listinfo/community
>
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
