Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of eevans@acunu.com designates
 209.85.210.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALdd-zgoeJx5WaOaOP3igtdjqPWF0kqSYqWJQirXk-g74h7NGw@mail.gmail.com>
References: 
 <CAL35Oi3qE=RYmFU7DobfxfQYLR9T2QmO3mZ41=tG5PNYCNU2Uw@mail.gmail.com>
	<CALdd-zgoeJx5WaOaOP3igtdjqPWF0kqSYqWJQirXk-g74h7NGw@mail.gmail.com>
Date: Thu, 25 Aug 2011 13:49:10 -0500
Message-ID: 
 <CAL35Oi2Adu+q0hCLJrO7=59oRVzTenyMfBPmHescm1ytf9ceLg@mail.gmail.com>
Subject: Re: CQL Drivers
From: Eric Evans <eevans@acunu.com>
To: dev@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2011 at 11:57 PM, Jonathan Ellis <jbellis@gmail.com> wrote:
> The JDBC problems can be subdivided into two categories: too-tight
> coupling that having it in-tree masks (but is really a problem either
> way), and java build systems being a PITA. =A0By the second part I mean,
> yes, we had JDBC building after the first month or so, but it still
> required that the main Cassandra source tree be checked out and built
> locally, with a cumbersome manual process to point the driver build to
> it.
>
> The build headache is actually a symptom of the coupling. =A0None of the
> other drivers have this problem; they were forced to do things
> "right"* instead of re-using things that shouldn't be re-used. =A0If we
> were going to take another stab at it we should fix this first. =A0(More
> accurately, we should fix it anyway whether we move drivers or not.)

The other drivers never had any choice but to create their own
implementations of term encoding/decoding, which you could probably
use as an argument for us inflicting this whole mess on ourselves with
the JDBC driver.  That said, I agree that the Right solution is still
to fix the tight coupling and reuse.

> The git mirror is also a symptom of a deeper problem. =A0Managing the
> drivers from the same Jira system as core is awkward too. =A0Nor does
> three-day release voting or patch-oriented development feel like a
> good fit for CQL drivers.

I emphatically agree.

> If we're going to move the drivers out-of-tree, why not move them all
> the way to github? =A0We'll still be able to link "official" drivers
> from cassandra.apache.org, so I'm not worried about the kind of
> fragmentation we have with Thrift clients today. =A0But if we want a
> little more official-ness, we could use Apache Extras on google code
> instead. =A0Which IMO has better bug tracker and code review systems,
> but I don't really have strong feelings either way.
>
> So, of the problems with the original move, the cqlsh "problem" is the
> only one that by definition can't be solved if we move the drivers out
> of tree. =A0I'm not enthusiastic about inflicting that on ourselves in
> exchange for problems with the git mirror. =A0But in exchange for a
> clean separation as a separate project? =A0That makes more sense to
> me.**

Setting aside my shock from a suggestion that is 1000 miles in the
opposite direction, I love it.

> * actually, relying on manual updating of Thrift is definitely
> suboptimal, but we've gotten away with it since the Thrift API hasn't
> been changing much. =A0A better solution might use an svn:external
> reference to the interface/ directory. =A0Not sure what we can do other
> than copy the .thrift file if we move to git though.

Maybe we should consider publishing releases of generated code
versioned using the VERSION constant.

> ** And yes, I do remember arguing for keeping them in-project
> originally. =A0Mea culpa.

--=20
Eric Evans
Acunu |=A0http://www.acunu.com=A0| @acunu