Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.210.171 as permitted sender)
	client-ip=209.85.210.171; envelope-from=bpcamac@gmail.com;
	helo=mail-ia0-f171.google.com; 
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Brenton Camac <bpcamac@gmail.com>
In-Reply-To: <CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
Date: Tue, 30 Apr 2013 15:06:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4EA3A617-AA9D-4E4B-B4CC-AC7BC28B2BB5@gmail.com>
References: <CAPg+sBjSe23eADMxu-1mx0Kg2LGkN+BSNByq0PtZcMxAMh0uTg@mail.gmail.com>
	<CANEZrP3FA-5z3gAC1aYbG2EOKM2eDyv7zX3S9+ia2ZJ0LPkKiA@mail.gmail.com>
	<CAAS2fgSo6Ua8giSKhYTjGm=2U1nBjprHOBqCL7dSNr9MQX_6tw@mail.gmail.com>
	<CAPaL=UUhrb+4CANVB6refCOeQwcf_A80Way_C_oJbDKM9kmWXg@mail.gmail.com>
	<CAAS2fgRR3K_dVMhOSHpga91tFaK7G99ouKLFpXHbgxEsvY+_Wg@mail.gmail.com>
	<CAPaL=UU8=EzhAni+rRtro4QZdgreUSJxeMpqJai19kGZ9JHTyg@mail.gmail.com>
	<20130429035523.GA11611@savin>
	<BLU0-SMTP4789CDF0A9814E7D8D2D662C8B20@phx.gbl>
	<CAFBxzACw=G7UgG853zQrM-Z1-B4VqSQR5YUJQ5n1=wnv7EyWsw@mail.gmail.com>
	<CAFBxzACmpODv-zvDb39TBpydSinwQ__BaPJfoVBeg==m7RLwrA@mail.gmail.com>
	<CA+8xBpcoTRfp=HFs4PdWAx1k_bZKRfopcTgeUpjPWSHRXv5qUA@mail.gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Service bits for pruned nodes
Precedence: list

Sounds like this part of Bitcoin (block sharing) would definitely =
benefit from having a REST (HTTP) API.

REST-based web APIs are a common feature of most online services these =
days.  Makes writing other client services so much easier.  Plus you get =
the benefit of the HTTP ecosystem for free (HTTP caches, etc).


- Brenton Camac=20


On Apr 30, 2013, at 1:04 PM, Jeff Garzik <jgarzik@exmulti.com> wrote:

> On Tue, Apr 30, 2013 at 12:14 PM, Rebroad (sourceforge)
> <rebroad+sourceforge.net@gmail.com> wrote:
>> As part of a roadmap for block downloading, I think this may be a =
good time
>> to look into providing an HTTP/HTTPS protocol for block downloading - =
this
>> would also allow web proxies to cache blocks and thus make it more
>> accessible, as well as cater for resumeable downloads.
>=20
> Speaking generally, I've always been a supporter of finding new and
> creative ways to store and transmit blocks.  The more diversity, the
> less likely bitcoin can be shut down worldwide.
>=20
> HTTP is fine, but you run into many issues with large files.  You
> would need a very well defined HTTP-retrievable layout, with proper
> HTTP headers along the entire path, if you want web caches to function
> properly.  You need HTTP byte range support, HTTP 1.1 keep-alives, and
> other features for resuming large, interrupted downloads.
>=20
> The format currently used by bitcoind would be just fine --
> blocks/blkNNNN.dat for raw data, size-limited well below 1GB.  Just
> need to add a small metadata download, and serve the raw block files.
>=20
> --=20
> Jeff Garzik
> exMULTI, Inc.
> jgarzik@exmulti.com
>=20
> =
--------------------------------------------------------------------------=
----
> Introducing AppDynamics Lite, a free troubleshooting tool for =
Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development