[cl-json-devel] proposed: improvements to decoder customization

Henrik Hjelte henrik at evahjelte.com
Mon Aug 4 10:47:36 UTC 2008


On Mon, Aug 4, 2008 at 1:58 AM, Hans Hübner <hans at huebner.org> wrote:

> I don't quite like the serialization mechanism that cl-json provides.
> The attempt to map from a Lisp datatype to a certain json structure is
> necessarily imperfect because no 1:1 relationship exists, and the
> requirement to first make up a data structure and then call
> encode-json to convert it to a json string is wasteful.

In principle yes. But to defend the current way, it make a clear division of
concerns, separating the code for formating output from the code for logic.

>
> A streaming serialization API is more useful, as one has more control
> over the json format that is being generated and the need to make up a
> data structure that can uniquely be mapped to json structures is
> removed.

I agree to a large degree, but in many situations it is nice to
have a simple to use format and API. What is simple is of course up
to debate. But in the sample below, I think cl-jsons current encoder
could save some code lines. But, why not have both, I am sure
there are lots of situations were your idea will be better?

In a way this is the reverse situation of the decoder issue that Boris
has.

> It is inspired by CXML's streaming serialization which I
> find very easy and straightforward to use.

It is the SAX thing that is used for serailization that is the inspiration?
CXML also has a klacks parser which is inspired from the Java
Streaming XML API, and I know there is a project jettison that
implements JSON for this API.

A cool feature would be if a json parser/serializer could be used as a
simple drop in replacement for an existing xml parser/geneneratior,
there are a few to choose from.


> This could certainly be improved, yet it works for me
I haven't looked much at the internals, but the API seems
very good from the example below.

> and I'd be glad
> to see this or a similar mechanism be integrated into cl-json.
>

I agree, I think we should do something along your lines in cl-json.
But I also want to preserve the current simple interface.

/Henrik

This is a neat sample from your code.
;;------------------------------------------------------------------------------
(defmethod handle-object ((handler json-news-archive-handler)
                          (channel rss-channel))
  (with-json-response ()
    (with-object-element ("months")
      (with-json-array ()
        (dolist (month (sort (rss-channel-archived-months channel)
                              (lambda (a b)
                                (if (= (first a) (first b))
                                    (> (second a) (second b))
                                    (> (first a) (first b))))))
          (with-json-array ()
            (encode-array-element (first month))
            (encode-array-element (second month))))))))

;;------------------------------------------------------------------------------
;; If I am not wrong, this is how it would look in the
;; current cl-json implementation.

(defmethod handle-object ((handler json-news-archive-handler)
                          (channel rss-channel))
  (encode-json-response ;; or similar
    (with-object-element ("months")
      (sort (rss-channel-archived-months channel)
                              (lambda (a b)
                                (if (= (first a) (first b))
                                    (> (second a) (second b))
                                    (> (first a) (first b))))))))



More information about the cl-json-devel mailing list