mirror of
git://git.psyc.eu/libpsyc
synced 2024-08-15 03:19:02 +00:00
conclusion moved
This commit is contained in:
parent
59fafcb5c0
commit
5a3fec3e7f
1 changed files with 48 additions and 43 deletions
|
@ -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
|
||||
performance impact this has.
|
||||
impractical to encode in JSON. We should probably
|
||||
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
|
||||
|
|
Loading…
Reference in a new issue