[Rprotobuf-commits] r834 - papers/jss

[noreply at r-forge.r-project.org]

Author: murray
Date: 2014-01-23 03:45:35 +0100 (Thu, 23 Jan 2014)
New Revision: 834

Modified:
   papers/jss/article.Rnw
Log:
Go back to dissing MessagePack and BSON since Jeroen pointed out some
limitations in the messagepack R package.  Remove citations to both,
and call them "not widely supported".

I think this wording is a fair compromise in that it still makes the
point I wanted to make that they address a shortcoming of text based
JSON for certain classes of applications by providing more efficient
binary encoding, but they make Jeroen's point that they still suck due
to lack of adoption and weak implementations for R packages so
shouldn't really be held up on the same level as JSON.

Add a paragraph break before we start talking about JSON, and merge
the binary json sentences into this new paragraph instead of being a
paragraph on their own.



Modified: papers/jss/article.Rnw
===================================================================
--- papers/jss/article.Rnw	2014-01-23 02:06:39 UTC (rev 833)
+++ papers/jss/article.Rnw	2014-01-23 02:45:35 UTC (rev 834)
@@ -5,6 +5,7 @@
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%5
 % Spelling Standardization:
 % Protocol Buffers, not protocol buffers
+% large-scale, not large scale
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %% declarations for jss.cls %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@@ -156,7 +157,7 @@
 Programming
 languages such as \proglang{R}, \proglang{Julia}, \proglang{Java}, and \proglang{Python} include built-in
 support for serialization, but the default formats 
-are usually language specific and thereby lock the user into a single
+are usually language-specific and thereby lock the user into a single
 environment.  
 
 %\paragraph*{Friends don't let friends use CSV!}
@@ -177,6 +178,7 @@
 very practical format to store numeric datasets as they appear in statistical
 applications.
 %
+
 A more modern, widely used format is \emph{JavaScript Object
   Notation} (\texttt{JSON}), which is derived from the object literals of
 \proglang{JavaScript}, and used increasingly on the world wide web. \texttt{JSON} natively
@@ -186,16 +188,21 @@
 leads to loss of type (double versus integer) and precision. Several \proglang{R} packages
 implement functions to parse and generate \texttt{JSON} data from \proglang{R}
 objects \citep{rjson,RJSONIO,jsonlite}.
-
 A number of binary formats based on \texttt{JSON} have been proposed
-that reduce the parsing cost and improve efficiency.  \pkg{MessagePack}
-and \pkg{BSON} both have \proglang{R}
-interfaces \citep{msgpackR,rmongodb}, but these formats lack a separate schema for the serialized
-data and thus still duplicate field names with each message sent over
-the network or stored in a file.  Such formats also lack support for
-versioning when data storage needs evolve over time, or when
-application logic and requirement changes dictate updates to the
-message format.
+that reduce the parsing cost and improve efficiency, but these formats
+are not widely supported.  Furthermore, such formats lack a separate
+schema for the serialized data and thus still duplicate field names
+with each message sent over the network or stored in a file.
+% and still must send duplicate field names
+% with each message since there is no separate schema.
+% \pkg{MessagePack}
+% and \pkg{BSON} both have \proglang{R}
+% interfaces \citep{msgpackR,rmongodb}, but these formats lack a separate schema for the serialized
+% data and thus still duplicate field names with each message sent over
+% the network or stored in a file.  Such formats also lack support for
+% versioning when data storage needs evolve over time, or when
+% application logic and requirement changes dictate updates to the
+%message format.
 
 Once the data serialization needs of an application become complex
 enough, developers typically benefit from the use of an