Return-Path: 
 <client-dev-return-58-apmail-cassandra-client-dev-archive=cassandra.apache.org@cassandra.apache.org>
Delivered-To: apmail-cassandra-client-dev-archive@minotaur.apache.org
Received: (qmail 65536 invoked from network); 5 Nov 2010 07:43:40 -0000
Received: from unknown (HELO mail.apache.org) (140.211.11.3)
  by 140.211.11.9 with SMTP; 5 Nov 2010 07:43:40 -0000
Received: (qmail 539 invoked by uid 500); 5 Nov 2010 07:44:12 -0000
Delivered-To: apmail-cassandra-client-dev-archive@cassandra.apache.org
Received: (qmail 418 invoked by uid 500); 5 Nov 2010 07:44:10 -0000
Mailing-List: contact client-dev-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:client-dev-help@cassandra.apache.org>
List-Unsubscribe: <mailto:client-dev-unsubscribe@cassandra.apache.org>
List-Post: <mailto:client-dev@cassandra.apache.org>
List-Id: <client-dev.cassandra.apache.org>
Reply-To: client-dev@cassandra.apache.org
Delivered-To: mailing list client-dev@cassandra.apache.org
Received: (qmail 400 invoked by uid 99); 5 Nov 2010 07:44:09 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Nov 2010 07:44:09 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=10.0
	tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of stuhood@mailtrust.com
 designates 207.97.245.191 as permitted sender)
Received: from [207.97.245.191] (HELO smtp191.iad.emailsrvr.com)
 (207.97.245.191)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Nov 2010 07:44:04 +0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by smtp39.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 1700D987A7
	for <client-dev@cassandra.apache.org>; Fri,  5 Nov 2010 03:43:43 -0400 (EDT)
X-Virus-Scanned: OK
Received: from dynamic4.wm-web.iad.mlsrvr.com
 (dynamic4.wm-web.iad1a.rsapps.net [192.168.2.153])
	by smtp39.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id F08FC98673
	for <client-dev@cassandra.apache.org>; Fri,  5 Nov 2010 03:43:42 -0400 (EDT)
Received: from mailtrust.com (localhost [127.0.0.1])
	by dynamic4.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id E22DB1D4A25E
	for <client-dev@cassandra.apache.org>; Fri,  5 Nov 2010 03:43:42 -0400 (EDT)
Received: by apps.rackspace.com
    (Authenticated sender: stuhood@mailtrust.com,
 from: stu.hood@rackspace.com)
    with HTTP; Fri, 5 Nov 2010 02:43:42 -0500 (CDT)
Date: Fri, 5 Nov 2010 02:43:42 -0500 (CDT)
Subject: Re: Calling all library maintainers
From: "Stu Hood" <stu.hood@rackspace.com>
To: client-dev@cassandra.apache.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
In-Reply-To: <1288900792.14765.32.camel@erebus.lan>
References: <1288887036.9620.33.camel@erebus.lan>  
 <AANLkTi=1g6KdxJeSzmeb41Z1ee3dOhjJ7uN0_Rpco8gq@mail.gmail.com>  
 <1288891732.9620.52.camel@erebus.lan>  
 <AANLkTin7UDnZ3rbzdUsGbBJpzkYzq=y2E9T4P1qvmgDw@mail.gmail.com>
 <1288900792.14765.32.camel@erebus.lan>
Message-ID: <1288943022.924912607@192.168.4.58>
X-Mailer: webmail8

> Java you serialize a type to a byte[] whereas with the query=0A> language=
 you'd serialize to a string term=0AThe "serializing to a byte[]" part is w=
hat the RPC libraries exist for. With a string serialization format, you ar=
e setting all of your clients up to become string concatenation engines wit=
h an ad-hoc format defined by your spec: essentially, duplicating Avro and =
Thrift.=0A=0A> TIMEUUID(<timestamp>)=0ANote that this same approach is poss=
ible in Avro by adding a union type: it is not dependent on String serializ=
ation.=0A=0A> to serialize that to a string like=0A> 100000L, than it would=
 be to pack a binary string in network-order=0AI don't think you are giving=
 client library devs enough credit: this only needs to be implemented once,=
 and I'm sure they're capable.=0A=0A=0A-----Original Message-----=0AFrom: "=
Eric Evans" <eevans@rackspace.com>=0ASent: Thursday, November 4, 2010 2:59p=
m=0ATo: client-dev@cassandra.apache.org=0ASubject: Re: Calling all library =
maintainers=0A=0AOn Thu, 2010-11-04 at 21:28 +0200, Ran Tavory wrote:=0A> A=
 QL can shield clients from a class of changes, but OTOH will make=0A> clie=
nts have to compose the query strings, where with type safe=0A> libraries t=
his job is somewhat easier. IMO in the near term=0A> introducing a query la=
nguage will make client dev somewhat harder b/c=0A> of the (somewhat neglig=
ible) work of composing query strings and=0A> mostly b/c I don't expect the=
 QL to be stable at v1 so still a moving=0A> target, but easier in the the =
long term mainly due to the hope that=0A> the QL will stabilize.=0A=0AI thi=
nk you could argue that it makes all of this easier.  Right now=0Afrom Java=
 you serialize a type to a byte[] whereas with the query=0Alanguage you'd s=
erialize to a string term.  That's a bit more effort out=0Aof the gate for =
primitives like long for example, but consider the=0Avenerable TimeUUID tha=
t causes so much frustration.  I think it would be=0Amuch easier to take a =
timestamp and construct a term like=0ATIMEUUID(<timestamp>) (or whatever), =
especially since that would work=0Aidentically across all clients.=0A=0AAnd=
 it's also worth pointing out that not all languages in use are=0Astaticall=
y typed, so even in the case of an int, or a long, it'd be=0Aeasier (or as =
easy at least), to serialize that to a string like=0A100000L, than it would=
 be to pack a binary string in network-order.=0A=0AAs for not being stable,=
 well, yeah it's going to need to bake a bit=0Abefore being suitable for wi=
despread use, but I raise it here not to=0Aencourage everyone to transition=
 now, but so that you can help shape the=0Aoutcome (if you're interested, o=
f course).=0A=0A> One other benefit of query languages is that they make to=
oling a=0A> little easier, one does not have to come up with a specific CLI=
=0A> interpreter or a web interface with a set of input fields, you just=0A=
> have to type your QL into a text box or a terminal like you do with=0A> s=
ql.=0A> Long term I think I'm in for a QL (although I have to think about t=
he=0A> syntax you suggested) but I don't expect it to benefit client devs i=
n=0A> the near term even if it was ready today as an alternative to thrift.=
=0A> =0A> One small question, does this language tunnel through avro or thr=
ift=0A> calls? (Is >>> conn.execute() an avro or thrift call) =0A=0AIt's av=
ro for the simple reason that that's still sort of an=0Aexperimental code p=
ath and seemed a less controverial sandbox.  When the=0Aspec and implementa=
tion are complete, and if it gains suitable traction,=0AI'd actually like t=
o explore a customized transport and serialization.=0A=0A-- =0AEric Evans=
=0Aeevans@rackspace.com=0A=0A