On Tue, 19 Jan 2010 08:09:13 -0600 Ted Zlatanov t...@lifelogs.com 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 -
+1
--
Jeff
On Tue, Jan 19, 2010 at 6:13 AM, Jonathan Ellis jbel...@gmail.com 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,
2010/1/15 Ted Zlatanov t...@lifelogs.com:
On Fri, 15 Jan 2010 09:23:08 -0800 Tatu Saloranta tsalora...@gmail.com
wrote:
TS 2010/1/15 Ted Zlatanov t...@lifelogs.com:
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.
On Thu, 14 Jan 2010 14:34:58 -0800 Tatu Saloranta tsalora...@gmail.com 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
2010/1/15 Ted Zlatanov t...@lifelogs.com:
...
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
On Wed, 13 Jan 2010 13:22:02 -0800 Tatu Saloranta tsalora...@gmail.com 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
2010/1/14 Ted Zlatanov t...@lifelogs.com:
On Wed, 13 Jan 2010 13:22:02 -0800 Tatu Saloranta tsalora...@gmail.com
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
On Wed, 13 Jan 2010 08:05:45 +1300 Michael Koziarski mich...@koziarski.com
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
On Sun, 10 Jan 2010 11:16:20 + Mark Robson mar...@gmail.com 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
2010/1/12 Ted Zlatanov t...@lifelogs.com:
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
2010/1/12 Ted Zlatanov t...@lifelogs.com
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.
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 look
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
13 matches
Mail list logo
