On Wed, Mar 24, 2010 at 8:45 AM, Ran Tavory <ran...@gmail.com> wrote: > I concur with Eric, as hector developer it's easier to develop separately > (github) plus competition keeps us healthy ;)
Enthusiastic +1 for this :) (both for proper layering to allow different levels of abstraction, and for goodness of some competition to keep everyone honest & hard-working) -+ Tatu +- > > On Wed, Mar 24, 2010 at 5:38 PM, Eric Evans <eev...@rackspace.com> wrote: >> >> On Wed, 2010-03-24 at 14:15 +0100, Roland Hänel wrote: >> > Still, I'm somewhat confused which API to choose if I was heading for >> > a >> > bigger project >> > >> > 1. plain Thrift (for Java)? >> > Seems the major advantage is that Thrift is available in many >> > languages, but >> > if I'm only interested in Java that doesn't give me much. The Java >> > code on >> > the native Thrift interface looks quite awful. It also seems to me as >> > if it >> > would result in many lines of code even for quite trivial jobs. >> >> Right, using raw Thrift means that you're interacting with the system by >> calling the RPC methods directly. You've got maximum flexibility but >> you're quickly going to notice a lot of boiler plate accumulating. >> >> > 2. a higher level Java Client? >> > I didn't look at Hector right now, however it confused me somewhat >> > that if >> > something like Hector was the "best choice", why isn't this then >> > bundled >> > with Cassandra? >> >> The "best choice" is always going to be subjective, but Hector has >> developed a lot of momentum in a short period of time. It would not be >> at all unreasonable to call it the de facto Java library for Cassandra. >> >> As for why it's not bundled, that is a feature and not a bug. As >> separate projects the two can move at their own pace, use the work-flow >> of their own choosing, pick the tools right for them, and add committers >> without the unwanted additional oversight. >> >> IMO, bundling Hector wouldn't enhance it's development, (if anything, it >> would inhibit it), and by sending the message that it was the One True >> Library it would unnecessarily close the door on competition. >> >> > 3. the "native Java fat Client" >> > I started some experiments with it, however couldn't get it completely >> > working, documentation in the Wiki is not really usuable at all. >> > Question >> > would be if this is something that you (the developers) consider as >> > the "big >> > thing for the future" or is this some niche for lets say high >> > performance >> > bulk jobs but not for the "everyday Java client program"? >> >> The fat client is different from Thrift in that it obtains a sort of >> limited membership in the cluster and is able to route requests directly >> to nodes, as opposed to the proxying that can occur when you make a >> Thrift call to a random node. >> >> The fat client is not as well tested, and it's true that we usually >> steer people toward Thrift unless they have specific requirements. If >> you're having problems though, we'd love to hear about them, either >> here, or in a bug report >> (https://issues.apache.org/jira/browse/CASSANDRA). >> >> >> -- >> Eric Evans >> eev...@rackspace.com >> > >
