conclusion moved

bench/benchmark.org

@@ -25,8 +25,9 @@ Here's a way to model this in PSYC:
 
 ** A message with JSON-unfriendly characters
 This message contains some characters which are
-impractical to encode in JSON. Let's see how much
+impractical to encode in JSON. We should probably
-performance impact this has.
+put a lot more inside to actually see an impact
+on performance.
 
 #+INCLUDE: packets/json-unfriendly.xml src xml
 #+INCLUDE: packets/json-unfriendly.json src js
@@ -34,7 +35,8 @@ performance impact this has.
 
 ** A message with XML-unfriendly characters
 Same test with characters which aren't practical
-in the XML syntax.
+in the XML syntax, yet we should put more of
+them inside.
 
 #+INCLUDE: packets/xml-unfriendly.xml src xml
 #+INCLUDE: packets/xml-unfriendly.json src js
@@ -170,6 +172,49 @@ not performed.
 
 These tests were performed on a 2.53 GHz Intel(R) Core(TM)2 Duo P9500 CPU.
 
+* Criticism
+
+Are we comparing apples and oranges? Yes and no, depends on what you
+need. XML is a syntax best suited for complex structured data in
+well-defined formats - especially good for text mark-up. JSON is a syntax
+intended to hold arbitrarily structured data suitable for immediate
+inclusion in javascript source codes. The PSYC syntax is an evolved
+derivate of RFC 822, the syntax used by HTTP and E-Mail, and is therefore
+limited in the kind and depth of data structures that can be represented
+with it, but in exchange it is highly performant at doing just that.
+In fact we are looking into suitable syntax extensions to represent
+generic structures and semantic signatures, but for now PSYC only
+provides for simple typed values and lists of typed values.
+
+Another aspect is the availability of these formats for spontaneous
+use. You could generate and parse JSON yourself but you have to be
+careful about escaping. XML can be rendered manually if you know your
+data will not break the syntax, but you can't really parse it without
+a bullet proof parser. PSYC is easy to render and parse yourself for
+simple tasks, as long as your body does not contain "\n|\n" and your
+variables do not contain newlines.
+
+After all it is up to you to find out which format fulfils your
+requirements the best. We use PSYC for the majority of messaging where
+JSON and XMPP aren't efficient and opaque enough, but we employ XML and
+JSON as payloads within PSYC for data that doesn't fit the PSYC model.
+For some reason all three formats are being used for messaging, although
+only PSYC was actually designed for that purpose.
+
+* Caveats
+
+In every case we'll compare performance of parsing and re-rendering
+these messages, but consider also that the applicative processing
+of an XML DOM tree is more complicated than just accessing
+certain elements in a JSON data structure or PSYC variable
+mapping.
+
+For a speed check in real world conditions which also consider the
+complexity of processing incoming messages we should compare
+the performance of a chat client using the two protocols,
+for instance by using libpurple with XMPP and PSYC accounts.
+To this purpose we first need to integrate libpsyc into libpurple.
+
 * Conclusions
 
 The Internet has developed two major breeds of protocol formats.
@@ -187,46 +232,6 @@ combines the compactness and efficiency of binary protocols with the
 extensibility of text-based protocols and still provides for enough
 data structuring to rarely require the use of other data formats.
 
-* Criticism
-
-Are we comparing apples and oranges? Yes and no, depends on what you
-need. XML is a syntax best suited for complex structured data in
-well-defined formats - especially good for text mark-up. JSON is a syntax
-intended to hold arbitrarily structured data suitable for immediate
-inclusion in javascript source codes. The PSYC syntax is an evolved
-derivate of RFC 822, the syntax used by HTTP and E-Mail, and is therefore
-limited in the kind and depth of data structures that can be represented
-with it, but in exchange it is highly performant at doing just that.
-
-So it is up to you to find out which format fulfils your
-requirements the best. We use PSYC for the majority of messaging where
-JSON and XMPP aren't efficient and opaque enough, but we employ XML and
-JSON as payloads within PSYC for data that doesn't fit the PSYC model.
-For some reason all three formats are being used for messaging, although
-only PSYC was actually designed for that purpose.
-
-Another aspect is the availability of these formats for spontaneous
-use. You could generate and parse JSON yourself but you have to be
-careful about escaping. XML can be rendered manually if you know your
-data will not break the syntax, but you can't really parse it without
-a bullet proof parser. PSYC is easy to render and parse yourself for
-simple tasks, as long as your body does not contain "\n|\n" and your
-variables do not contain newlines.
-
-* Caveats
-
-In every case we'll compare performance of parsing and re-rendering
-these messages, but consider also that the applicative processing
-of an XML DOM tree is more complicated than just accessing
-certain elements in a JSON data structure or PSYC variable
-mapping.
-
-For a speed check in real world conditions which also consider the
-complexity of processing incoming messages we should compare
-the performance of a chat client using the two protocols,
-for instance by using libpurple with XMPP and PSYC accounts.
-To this purpose we first need to integrate libpsyc into libpurple.
-
 * Futures
 
 After a month of development libpsyc is already performing pretty