incubator-cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Evans <eev...@rackspace.com>
Subject Implementing [was: NoSQL, YesCQL?]
Date Fri, 29 Oct 2010 19:53:27 GMT
On Thu, 2010-10-28 at 15:40 -0500, Eric Evans wrote:

[ ... ]

> One solution to this is to implement a server-side query language, with
> simple language drivers that manage all of the common functionality in a
> consistent way (statement preparation, connection pooling, etc).
> Library maintainers would then build their idiomatic interfaces on top
> of these, (and I imagine, remove a metric crap-ton of code in the
> process).

[ ... ]

> I've been chewing on all of this for a while so I'm brimming with ideas,
> but I'll let the dust settle on this email before going any further. :)

Since it looks like most people are receptive to the general idea, maybe
I'll push my luck a little further by talking about implementation.

What I've been bouncing around in my head is this:

1. Implement it in the Avro interface.
2. As new statements are added, mark the corresponding (avro) RPC
methods as deprecated (or remove immediately).
3. When the query language has reached 100% feature coverage, the
language specification transitions to 1.0, and <insert sane process TBD
for change management>.
4. (Optionally )code our own transport and result serialization, and
remove Avro as a dependency.
5. Profit.

The rationale behind #1 and #2 is that the Avro interface is still
considered experimental, nothing that goes on there directly impacts the
supported API, and it has little to no existing user-base (that we know
of).  The existing parity with the Thrift interface means that the query
language can be built out incrementally since holes in functionality can
be plugged with the RPC methods.  Ultimately I favor the complete
elimination of the RPC methods because, well, as I've already stated I'm
not a fan and so see no reason to maintain *two* forms for the duration.

#3 is just about managing expectations.  I don't favor anything overly
bureaucratic; I do favor heavily engaging library maintainers.

As for #4, this falls into the nice to have category, but at this stage
in the game, we'd only be using a tiny fraction of what these frameworks
provide.  Creating our own wire protocol would allow us to shed a
dependency and optimize for our specific use.

Thoughts?

-- 
Eric Evans
eevans@rackspace.com


Mime
View raw message