Peter,
I didn't specifically call it out, but the interface I just proposed in my
last email would be very much with the goal of "make writing complex
queries less painful and more efficient." by providing a deep integration
mechanism to host that code. It's very much a "enough rope to hang
ourselves" approach, but badly needed, IMO
-Tupshin
On Mar 12, 2014 12:12 PM, "Peter Lin" <wool...@gmail.com> wrote:
>
> @Nate
> I don't want to change the separation of components in cassandra. My
> ultimate goal is "make writing complex queries less painful and more
> efficient." How that becomes reality is anyone's guess. There's different
> ways to get there. I also like having a plugging transport layer, which is
> why I feel sad every time I hear people say "thrift is dead" or "thrift is
> frozen beyond 2.1" or "don't use thrift". When people ask me what to learn
> with Cassandra, I say both thrift and CQL. Not everyone has time to read
> the native protocol spec or dive into cassandra code, but clearly "some"
> people do and enjoy it. I understand some people don't want the burden of
> maintaining Thrift, and it's totally valid. It's up to those that want to
> keep thrift to make sure patches and enhancements are well tested and solid.
>
>
>
>
>
> On Wed, Mar 12, 2014 at 11:52 AM, Nate McCall <n...@thelastpickle.com>wrote:
>
>> IME/O one of the best things about Cassandra was the separation of (and
>> I'm over-simplifying a bit, but still):
>>
>> - The transport/API layer
>> - The Datacenter layer
>> - The Storage layer
>>
>>
>> > I don't think we're well-served by the "construction kit" approach.
>> > It's difficult enough to evaluate NoSQL without deciding if you should
>> > run CQLSandra or Hectorsandra or Intravertandra etc.
>>
>> In tree, or even documented, I agree completely. I've never argued CQL3
>> is not the best approach for new users.
>>
>> But I've been around long enough that I know precisely what I want to do
>> sometimes and any general purpose API will get in the way of that.
>>
>> I would like the transport/API layer to at least remain pluggable
>> ("hackable" if you will) in it's current form. I really just want to be
>> able to create my own *Daemon - as I can now - and go on my merry way
>> without having to modify any internals. Much like with compaction
>> strategies and SSTable components.
>>
>> Do you intend to change this current behavior of allowing a custom
>> transport without code modification? (as opposed to changing the daemon
>> class in a script?).
>>
>>
>
