I created this patch before I got your email.  What my usage is now the following:<br><br>    (let ((json:*json-identifier-name-to-lisp* 'identity)<br>          (json:*json-symbolize-lisp-key* 'identity))<br>      (json:decode-json-from-string json))<br>
<br>The patch is attached:<br><br><br><br>I have not taken the time to read through how the accumulator works.  This approach modifies the default behavior in a more fine-grained way.<br><br><br><br><div class="gmail_quote">
On Thu, Jun 25, 2009 at 1:29 PM, Boris Smilga <span dir="ltr"><<a href="mailto:boris.smilga@gmail.com">boris.smilga@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 25 Jun 2009, at 22:27, Red Daly wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
CL-JSON does not allow the user to customize the means used to decode the keys for object literals.  It may be important to avoid interning in a web setting, for example, since interns of many unique symbols could potentially use a lot of memory.  An attack could exploit this by submitting something that is passed through cl-json that has many very large, unique symbols.<br>

</blockquote>
<br></div>
Indeed, thank you for pointing this out.<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There used to be a way to get around this with the factory method customization, but the current library does not include a means of changing the decoding behavior for a key to avoid interning it.  [...]<br>
</blockquote>
<br>
It is the same thing in the new version, except that customization works in a somewhat different way.  Broadly speaking, you have to redefine the way a level of JSON Object structure is accumulated to form the corresponding Lisp structure.  E. g., in the following example new (KEY . VALUE) pairs are clipped onto the end of a list accumulator, to form an alist: </blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
  (defvar *accumulator* nil)<br>
  (defvar *accumulator-last* nil)<br>
<br>
  (defun init-accumulator ()<br>
    (setq *accumulator* (cons nil nil)<br>
          *accumulator-last* *accumulator*))<br>
<br>
  (defun collect-key (key)<br>
    (setq *accumulator-last*<br>
          (setf (cdr *accumulator-last*)<br>
                (cons (cons key nil) nil))))<br>
<br>
  (defun collect-value (value)<br>
    (setf (cdar *accumulator-last*) value))<br>
<br>
  (defun accumulator-get-value ()<br>
    (cdr *accumulator*))<br>
<br>
  (json:bind-custom-vars<br>
      (:beginning-of-object #'init-accumulator<br>
       :object-key #'collect-key<br>
       :object-value #'collect-value<br>
       :end-of-object #'accumulator-get-value<br>
       :object-scope '(*accumulator* *accumulator-last*))<br>
    (json:decode-json-from-string<br>
      "{\"foo\": [{\"bar\": \"xyzzy\"}, {\"baz\": true}],<br>
        \"quux\": 123}"))<br>
<br>
  => (("foo" (("bar" . "xyzzy")) (("baz" . T))) ("quux" . 123))</blockquote><div><br>Thanks for an example of a custom accumulator modification.  Just out of curiosity, have you seen the accumulator paradigm crop up in other contexts?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[...] Unless I am missing something, could this functionality be added?<br>
</blockquote>
<br>
<br>
No problem, but could you maybe provide a sample of phantasy code which showed how this kind of customization interface should look from the user's side?  With that, we'll be more able to meet your expectations.  (I cannot, of course, guarantee that your interface shall be reproduced 100% exactly, rather it'll serve as a guideline.)</blockquote>
<div><br>It would be nice to have something like:<br><br>(let ((json:*json-symbolize-lisp-key* 'identity))<br>  ...)<br><br>This is still a little confusing unless you are familiar with the *json-identifier-name-to-lisp* variable, in which case it makes a little more sense.<br>
 </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Yours,<br>
 - B. Smilga.<br>
<br>
</blockquote></div><br><br>-Red<br><br><br>patch:<br>diff -rN old-cl-json/src/common.lisp new-cl-json/src/common.lisp<br>94a95,98<br>> <br>> (defvar *json-symbolize-lisp-key* 'json-intern<br>>   "Designator for a function which, during decoding, maps the *json-identifier-name-to-lisp*<br>
> -transformed key to the value it will have in the result object.")<br>\ No newline at end of file<br>diff -rN old-cl-json/src/decoder.lisp new-cl-json/src/decoder.lisp<br>474c474<br><   (let ((key (json-intern (funcall *json-identifier-name-to-lisp* key))))<br>
---<br>>   (let ((key (funcall *json-identifier-name-to-lisp* key)))<br>604,605c604,605<br><              (string (json-intern<br><                       (funcall *json-identifier-name-to-lisp* value)))<br>---<br>
>              (string (funcall *json-symbolize-lisp-key*<br>>                   (funcall *json-identifier-name-to-lisp* value)))<br>609c609<br><               collect (cons (json-intern key) value))))<br>---<br>
>               collect (cons (funcall *json-symbolize-lisp-key* key) value))))<br>diff -rN old-cl-json/src/package.lisp new-cl-json/src/package.lisp<br>16a17<br>>    #:*json-symbolize-lisp-key*<br><br>