1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
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 <marek@palatinus.cz>) 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 <bitcoin-development@lists.sourceforge.net>;
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>
<CAJna-HjyZv2y9grNdnKKG8k6tn7jdW=zL=vtrALpeW8jkuzV6Q@mail.gmail.com>
<CAGQP0AEEzOjc2ayOJYgs_oh4RG91Dp4JSHUjyPX=qdp+ri6oSg@mail.gmail.com>
<201112191130.43721.luke@dashjr.org> <4EEF6EA2.4060709@parhelic.com>
From: slush <slush@centrum.cz>
Date: Mon, 19 Dec 2011 18:09:16 +0100
X-Google-Sender-Auth: P69YXtJHMM-CzNI52kv-FMBUT0s
Message-ID: <CAJna-HgjkC95pt+REmLi2tUh7MVmP-nYwLgzCzrK78qBmEcE_Q@mail.gmail.com>
To: Jordan Mack <jordanmack@parhelic.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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 <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 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.<div><br></div><div>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).</div>
<div><br></div><div>slush<br><br><div class=3D"gmail_quote">On Mon, Dec 19,=
2011 at 6:04 PM, Jordan Mack <span dir=3D"ltr"><<a href=3D"mailto:jorda=
nmack@parhelic.com">jordanmack@parhelic.com</a>></span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">
I thought that JSON support was fairly common these days. I personally<br>
prefer XML in most cases, but since JSON is already used with the RPC,<br>
it seemed like a natural fit here. Binary data can be base64 encoded,<br>
although I'm not sure why you would need to send back binary in an alia=
s<br>
response.<br></blockquote></div></div>
--001517402a808d570304b475045e--
|
