I concur with Eric, as hector developer it's easier to develop separately (github) plus competition keeps us healthy ;)
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 > >
