Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <AANLkTikfQJLUdEC42F92KRXgRpe1lQZ6xN8rvns349sU@mail.gmail.com>
References: 
 <5A4D71ACC2708E4BB1BD7B6F87E51C6B07FA3B27@sccorpmail01.mygazoo.com>
	<AANLkTinHPluEGebYQGhBGOmsV28EYExZjxyFenqTsjwY@mail.gmail.com>
	<AANLkTinD6sJkN01Owb0sMG_GnuWAKeE1eLv9QXAh-dDK@mail.gmail.com>
	<AANLkTim5ebzRLASuBDaxe2e6LczDTIfGkV5o5jFoL33R@mail.gmail.com>
	<AANLkTikfQJLUdEC42F92KRXgRpe1lQZ6xN8rvns349sU@mail.gmail.com>
Date: Tue, 29 Jun 2010 17:21:48 -0700
Message-ID: <AANLkTilVToBXSOnTe79dGd1NIrkViI0N7ID6-5jvFYke@mail.gmail.com>
Subject: Re: Cassandra and Thrift on the Server Side
From: Mike Malone <mike@simplegeo.com>
To: user@cassandra.apache.org
Content-Type: multipart/alternative; boundary=000e0cd184fcf3a930048a3456f5

--000e0cd184fcf3a930048a3456f5
Content-Type: text/plain; charset=ISO-8859-1

>
> Still, to Clint's point, everyone knows how to make an HTTP request. If you
> want a cassandra client running on, let's say, an iPhone for some reason, a
> REST API is going to be a lot more straight forward to implement.


There's no reason an HTTP service would have to live inside the Cassandra
project though, right... we're just talking about a proxy that translates
from one protocol (HTTP) to another (thrift / avro). Shouldn't be too hard
to implement. It could even be open sourced, and referenced from the
Cassandra website, maybe even endorsed by the Cassandra project. High level
though I think it's important to resist the temptation to build things in
that could just as easily live separately and develop orthogonally.

I feel the same way about access control... I think it's more natural and
flexible for that to be handled in an application rather than in the
database... If your particular requirements end up pushing access control
back to the data store tier than it should be fairly easy to wrap the
Cassandra service at either the Java level (by subclassing) or the OS level
(by having Cassandra listen only on localhost and have an authenticating /
authorizing proxy listen for remote requests & forward). But it looks like
that decision has already been made.

Mike

--000e0cd184fcf3a930048a3456f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Still, to Clint&=
#39;s point, everyone knows how to make an HTTP request. If you want a cass=
andra client running on, let&#39;s say, an iPhone for some reason, a REST A=
PI is going to be a lot more straight forward to implement.</blockquote>
<div><br></div><div>There&#39;s no reason an HTTP service would have to liv=
e inside the Cassandra project though, right... we&#39;re just talking abou=
t a proxy that translates from one protocol (HTTP) to another (thrift / avr=
o). Shouldn&#39;t be too hard to implement. It could even be open sourced, =
and referenced from the Cassandra website, maybe even endorsed by the Cassa=
ndra project. High level though I think it&#39;s important to resist the te=
mptation to build things in that could just as easily live separately and d=
evelop orthogonally.</div>
<div><br></div><div>I feel the same way about access control... I think it&=
#39;s more natural and flexible for that to be handled in an application ra=
ther than in the database... If your particular requirements end up pushing=
 access control back to the data store tier than it should be fairly easy t=
o wrap the Cassandra service at either the Java level (by subclassing) or t=
he OS level (by having Cassandra listen only on localhost and have an authe=
nticating / authorizing proxy listen for remote requests &amp; forward). Bu=
t it looks like that decision has already been made.</div>
<div><br></div><div>Mike</div></div>

--000e0cd184fcf3a930048a3456f5--