Hi there,
I encountered an interesting issue today while working with an API. In some of its strings, it basically had some CSS from Word or a Word-like program. Long story short, I found that the preg_replace in extras/jsonrpc/jsonrpc.inc:json_parse was truncating the whole string because of that! Obviously, the regexes need a bit of work to only remove the comment. I can see, for example, that the backreferences don't look right.
Truth be told, though, I don't need that functionality at all for the data I am retrieving, so I patched it to allow turning off the functionality. Since that's an optimization point, maybe this will also slightly improve the performance. In any case, it stopped json[_alt]_decode from erroring out on syntax - the syntax error being an empty string, of course.
Thought I would submit a patch in case this throws out anyone else. It is probably not implemented in the best possible way because I haven't had the time to review all the code or learn its patterns; however, at first glance it seems to more or less follow the same code conventions as similar functions. For example, I simply pass the $options array to json_parae and then check for a particular key. Actually, json_extension_api.inc:json_decode also needs an $options parameter ($options = array())...but that is easy to add, doesn't really need a patch.
Thanks for creating this library. The default PHP 5.2 json_decode, at least on my testing system, will only let me parse a handful of records, meaning I'd have to page like crazy. This one can handle all 200, even if it takes a few seconds :) - and it's probably the most portable. I could have gone with PEAR, but then I'd have to get all my users to install the Services_JSON package...better to just be able to bundle things...
Regards,
Kevin
Anonymous
Patch for extras/jsonrpc/jsonrpc.inc
Forgot to mention that this patch is for 3.3.0-beta.
Thanks for the heads-up.
The json parser included in this library is far from being optimized in either speed or memory usage, but I never had enough time to rewrite it 'properly'.
Otoh i did some extensive testing on corner cases, and the parser strives to accept as valid everything that the native js parsers of common browsers do (i tested with IE and FF a while ago, more info here: http://gggeek.altervista.org/2007/04/25/a-comparison-of-json-libraries-for-php-reloaded/
Thanks for your feedback! Well, I'm using it in a project I hope will get at least moderate attention/usage, so perhaps some more people still on PHP 5.2 will be interested in submitting patches to improve the library.
Is there a place I can see your to-do list on it or could you outline it briefly? Assuming you have something in mind for what you'd like to do to improve the speed/memory usage.
I'm sorry, but my main goals right now are stability and defect fixing. I do not have enough free time to embark on major works such as a rewrite of the json parser (esp. considering the json extension that has been native in php for quite a while). I have been considering trying to use the xmlreader extension and compare the speed/memory differences vs. the current xml parser, but that too is currently on the back burner.
A somewhat outdated to-do list you can find on the project's homepage.