HN user

dogada

82 karma

Blog: https://dogada.org

My projects: MetaJS - logos-oriented lisp compiled to Javascript, universal communication protocol Coect.net.

I use Javascript and Python.

Posts13
Comments16
View on HN

A year ago near last Google Reader redesign I made my own online RSS-reader http://www.cliws.com/ and now don't care.

We should less depend on the large corporations. The idea about I think last time is that we need some kind of distributed Twitter (like we have perfectly worked distributed email now).

If you can't replace one tool with another you are in trouble definitely.

I understand you but DSLs allows to reduce number of used languages/tools in a web-projects.

For example NodeJs allows to use same JavaScript for both client and server and if we will have smth like http://lispyscript.com/docs/#templates we can also seamless export business logic into templates (without need to create special template tags, filters, syntax, etc).

Single language for almost everything can be big performance boost IMO.

On algorithmic level compression is mainly identical to JSONH. I didn't do performance tests yet, I still have ideas how to improve RJSON.

I agree that identification is important issue, but IMO it's protocol level issue. RJSON is not protocol, it's algorithm. Someone will prefer to wrap all in {"rjson": ...}, someone like {"format": "rjson", "data": ...} and so on. I belive, algorithm itself should create as less limitations as possible.

RJSON not only compresses data of any structure but keeps it in JSON format that is huge advantage over gzip/7z and other binary compression algorithms. You can compress 1M of JSON to 300Kb of gzipped JSON but then you will to parse 1Mb of JSON on client anyway. With RJSON you can compress 1Mb of JSON to 500Kb of RJSON, then gzip it down to 200Kb and parse only 500Kb of JSON. Then you can analyze some core properties of parsed RJSON document and unpack it on demand. For example you may send to client collection of 20 documents, parse each and show title of each document to the client, then fully unpack only selected by client document.

I agree with Too that specialized protocol will always win, but RJSON IMO decreases structural entropy almost to 0 without need to debugging own protocol.

Exactly, ZenPsycho, the purpose of RJSON is to convert data with dynamic schema. Fields with default values are omitted often, for example if most of data have 'private' property set to False, it have sense to output it only for 1% of objects with 'private' set to True. This issue is addressed in RJSON.

[dead] 14 years ago

More details about the problem: http://code.google.com/p/googleappengine/issues/detail?id=71...

Stack trace from the logs of http://www.cliws.com/ on App Engine:

  async response_handler xml_url=http://news.ycombinator.com/rss
  Traceback (most recent call last):
  File "/base/data/home/apps/s~cliwws/dev.357649535611989626/core/channel.py", line 106, in response_handler
    return handle_feed_response(channel, rpc.get_result())
  File "/base/python27_runtime/python27_lib/versions/1/google/appengine/api/apiproxy_stub_map.py", line 592, in get_result
    return self.__get_result_hook(self)
  File "/base/python27_runtime/python27_lib/versions/1/google/appengine/api/urlfetch.py", line 365, in _get_fetch_result
    raise DownloadError(str(err))
  DownloadError: ApplicationError: 2