Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Rcgit-0003um-E3 for bitcoin-development@lists.sourceforge.net; Mon, 19 Dec 2011 17:09:59 +0000 X-ACL-Warn: Received: from mail-ey0-f175.google.com ([209.85.215.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Rcgin-0006Vo-OB for bitcoin-development@lists.sourceforge.net; Mon, 19 Dec 2011 17:09:59 +0000 Received: by eaal1 with SMTP id l1so7165702eaa.34 for ; Mon, 19 Dec 2011 09:09:47 -0800 (PST) Received: by 10.205.132.14 with SMTP id hs14mr1958492bkc.130.1324314587387; Mon, 19 Dec 2011 09:09:47 -0800 (PST) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.204.168.15 with HTTP; Mon, 19 Dec 2011 09:09:16 -0800 (PST) In-Reply-To: <4EEF6EA2.4060709@parhelic.com> References: <1323728469.78044.YahooMailNeo@web121012.mail.ne1.yahoo.com> <201112191130.43721.luke@dashjr.org> <4EEF6EA2.4060709@parhelic.com> From: slush Date: Mon, 19 Dec 2011 18:09:16 +0100 X-Google-Sender-Auth: P69YXtJHMM-CzNI52kv-FMBUT0s Message-ID: To: Jordan Mack Content-Type: multipart/alternative; boundary=001517402a808d570304b475045e X-Spam-Score: 1.3 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message 0.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1Rcgin-0006Vo-OB Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] [BIP 15] Aliases X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 17:09:59 -0000 --001517402a808d570304b475045e Content-Type: text/plain; charset=ISO-8859-1 I agree with Luke that HTTP standard has everything necessary and bloating payload with json/xml is not necessary. Btw that argument "we have json in client already" seems pretty wrong, because json in server rpc solves another problem (and solve it in wrong way, because of data type issues, but it's another story). slush On Mon, Dec 19, 2011 at 6:04 PM, Jordan Mack wrote: > I thought that JSON support was fairly common these days. I personally > prefer XML in most cases, but since JSON is already used with the RPC, > it seemed like a natural fit here. Binary data can be base64 encoded, > although I'm not sure why you would need to send back binary in an alias > response. > --001517402a808d570304b475045e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Luke that HTTP standard has everything necessary and bloating = payload with json/xml is not necessary.

Btw that argumen= t "we have json in client already" seems pretty wrong, because js= on in server rpc solves another problem (and solve it in wrong way, because= of data type issues, but it's another story).

slush

On Mon, Dec 19,= 2011 at 6:04 PM, Jordan Mack <jordanmack@parhelic.com> wrote:
I thought that JSON support was fairly common these days. I personally
prefer XML in most cases, but since JSON is already used with the RPC,
it seemed like a natural fit here. Binary data can be base64 encoded,
although I'm not sure why you would need to send back binary in an alia= s
response.
--001517402a808d570304b475045e--