no-JSON : from Curl data to serialized object - Printable Version +- Curl Global Community (https://communities.curl.com) +-- Forum: Blogs (https://communities.curl.com/forumdisplay.php?fid=17) +--- Forum: Tech blog (https://communities.curl.com/forumdisplay.php?fid=18) +---- Forum: Robert blog (https://communities.curl.com/forumdisplay.php?fid=20) +---- Thread: no-JSON : from Curl data to serialized object (/showthread.php?tid=514)

no-JSON : from Curl data to serialized object - RobertShiplett - 06-01-2012 In keeping with no-SQL, I couldn't resist no-JSON. But seriously, once a large data set is in a Curl format - such as the dictionary entries that I use over at kanji.aule-browser.com - the next thing is simply to serialize the input source objects. What I am looking at for now is to hold my annotations within the live dict as transient fields, but to save them in a universal format such as JSON. I do sometimes modify the dictionary entries by adding words: the entry for "fragrance, smell, perfume" was missing "scent", for example. In addition, on-line resources such as the edict2 go through routine updates with new entries and other changes. These must pass through at least one iterator and then the object undergo a repeat serialization as a Curl binary resource file. Serialization is a great strength of the Smalltalk programming environment and it can be as important for a Curl app which is not using SQL tables. There are comparable features in the great PDC dialect of PROLOG. At http://www.aule-browser.com/kanji/poets/basho-complete-indexed.html I have an applet loading 980 items from a serialized source. The applet uses the {deserialize } macro and displays a minimum number of columns (the other related information now resides in a second and third serialized source file, hence the indices.) The serialized output is created using simple calls to a stream, e.g., {strm.write-one my-array} with the serialization protocol left as the default for Curl 8.0 (which is the curl7 protocol.) This approach will speed up all of the applets for my "learn kanji" pages without the risk of any duplication of the original text data - which itself can be refreshed as needed and the serialized files re-created in batch. All that was necessary was to declare my two main classes as serializable and to ensure that all text fields were declared using a default of {uninitialized-value-for-type String} to avoid any problematic values for transient fields (those fields get serialized on their own using the index for the parent object.) Here is the result: But. To see the real effect just look at the speed of the small daily pages such as http://www.aule-browser.com/kanji/poets/basho-mee-indexed.html The new daily page generated fast and it loads very fast. I have already cycled twice through the BIN serialization files as I find minor transcription errors in the principal text resource - but that text resource now does not need to reside on the applet web server !