On Tue, 19 Jan 2010 08:09:13 -0600 Ted Zlatanov wrote:
TZ> My proposal is as follows:
TZ> - provide an IPluggableAPI interface; classes that implement it are
TZ> essentially standalone Cassandra servers. Maybe this can just
TZ> parallel Thread and implement Runnable.
TZ> - enable the user
Ted Zlatanov wrote:
>>> I've got three (me, Tatu, Philip) in favor of such an interface.
>>> Jonathan, Eric, anyone else, WDYT?
>>>
>>> My proposal is as follows:
>>>
>>> - provide an IPluggableAPI interface; classes that implement it are
>>> essentially standalone Cassandra servers. Maybe this
+1
--
Jeff
On Tue, Jan 19, 2010 at 6:13 AM, Jonathan Ellis wrote:
> I'm a huge non-fan of the "let's specify everything in as minute
> detail as possible before writing anything" style that resulted in
> CASSANDRA-547 taking about ten times as long as necessary. Code
> something up, if the appro
I'm a huge non-fan of the "let's specify everything in as minute
detail as possible before writing anything" style that resulted in
CASSANDRA-547 taking about ten times as long as necessary. Code
something up, if the approach has merit, it can be refined.
-Jonathan
2010/1/19 Ted Zlatanov :
> On
On Mon, 18 Jan 2010 10:48:41 -0800 Tatu Saloranta wrote:
TS> 2010/1/15 Ted Zlatanov :
>> I could provide a way to plug in your own API to Cassandra so anyone
>> could write a full API using PB, HTTP, or whatever protocol they like.
>> Underneath it could invoke the Thrift interface methods local
2010/1/15 Ted Zlatanov :
> On Fri, 15 Jan 2010 09:23:08 -0800 Tatu Saloranta
> wrote:
>
> TS> 2010/1/15 Ted Zlatanov :
>>> Hell, let's make the query a RESTful HTTP GET, Cassandra a HTTP
>>> server, and return the data as JSON if it's more palatable. My point
>>> is, string queries are a
>
> TS>
My application uses cassandra in this way - basically a HTTP RESTful
interface for the data and
it is returned in JSON format. I would be super interested in anything that
would eliminate my
custom python code for doing this.Basically I just hard-coded the stuff
that I needed - but a
flexible
On Fri, 15 Jan 2010 09:23:08 -0800 Tatu Saloranta wrote:
TS> 2010/1/15 Ted Zlatanov :
>> Hell, let's make the query a RESTful HTTP GET, Cassandra a HTTP
>> server, and return the data as JSON if it's more palatable. My point
>> is, string queries are a
TS> No contest there. :-)
If anyone, inc
2010/1/15 Ted Zlatanov :
...
> So coming back to the query language, you either simulate OO queries,
> which Thrift already does as badly as can be expected, or you drop down
> to multiple strings, which IMHO is a bad compromise, or you use a single
> string like most universal APIs in existence.
On Thu, 14 Jan 2010 14:34:58 -0800 Tatu Saloranta wrote:
TS> No specific proposal, or immediate need. But I do know that such
TS> short-hand notations / languages are popular for accessing structured
TS> data (xpath/xquery, oql, even sql).
Sure. The idea is to make Cassandra more accessible.
2010/1/14 Ted Zlatanov :
> On Wed, 13 Jan 2010 13:22:02 -0800 Tatu Saloranta
> wrote:
>
> TS> I think there are 2 separate questions:
>
> TS> (a) Would a path language make sense, and
> TS> (b) How would that be exposed
>
> TS> So I think more developers would be opposed to part (b) of exposing
>
On Wed, 13 Jan 2010 13:22:02 -0800 Tatu Saloranta wrote:
TS> I think there are 2 separate questions:
TS> (a) Would a path language make sense, and
TS> (b) How would that be exposed
TS> So I think more developers would be opposed to part (b) of exposing
TS> path queries using opaque things like
2010/1/13 Ted Zlatanov :
> On Wed, 13 Jan 2010 08:05:45 +1300 Michael Koziarski
> wrote:
>
>>> I see no value in pushing for ports of a Perl library to other
>>> languages instead of allowing each to grow its own idiomatic one.
>
> MK> That's definitely the way to go, the Easy.pm magic strings lo
On Wed, 13 Jan 2010 08:05:45 +1300 Michael Koziarski
wrote:
>> I see no value in pushing for ports of a Perl library to other
>> languages instead of allowing each to grow its own idiomatic one.
MK> That's definitely the way to go, the Easy.pm magic strings look a
MK> little like line noise to
> I see no value in pushing for ports of a Perl library to other
> languages instead of allowing each to grow its own idiomatic one.
That's definitely the way to go, the Easy.pm magic strings look a
little like line noise to me ( a non-perler ) and I'm sure the
invocations in the cassandra gem loo
2010/1/12 Ted Zlatanov
> Map latest = client.get(new String[] { "row1" }, "Values/<-1>[]");
>
Reminds me of the old colon-separated CF format. I'm not fond of passing
parameters to my functions that have their own special syntax. +1 to
language-specific idiomaticness instead.
-Brandon
2010/1/12 Ted Zlatanov :
> If no one else sees value in it, I'll keep the "easy" interface as a
> Perl module and release on CPAN. Can I get some more opinions?
I see no value in pushing for ports of a Perl library to other
languages instead of allowing each to grow its own idiomatic one.
-Jonat
On Sun, 10 Jan 2010 11:16:20 + Mark Robson wrote:
MR> I can't see any reason to make an "easy" Cassandra interface, as the Thrift
MR> interface isn't really very difficult.
Compare this (this is what the "easy" interface would look like in Java,
wrapped in try/catch of course):
EasyCassand
I can't see any reason to make an "easy" Cassandra interface, as the Thrift
interface isn't really very difficult.
In any case the main problems with Cassandra will be design ones, i.e.
figuring out how to use it effectively in your application. No "Easy"
library is going to make that easier.
Mar
I was wondering if it would make sense to add the pseudo-language
EasyCassandra.pm uses right into Cassandra and expose it over Thrift.
Here's a summary of the requests supported by this language:
# read and remove requests:
# "X/[Y][A,B]": supercolumn family X, super column Y (not a time
20 matches
Mail list logo
