Hey Jon, Any chance you want to implement the RawClient interface (https://github.com/basho/riak-java-client/blob/master/src/main/java/com/basho/riak/client/raw/RawClient.java) from the basho riak-java-client library? That way your client can be swapped straight into the basho lib?
If not, let me know when you get a repo up on github and I'll write an adapter so that the basho riak-java-client can make use of your Grizzly client, which I guess means I'll pitch in a little (time permitting) to help shape the Grizzly client so it is RawClient shaped. Cheers Russell On 21 Jun 2011, at 17:58, Jon Brisbin wrote: > I'm trying to get my feet wet with Grizzly on another project, so I've been > spending some late(ish) nights also working on a Grizzly-based asynchronous > PB client for Riak. I'm dropping all the way down to the protobuf level and > using Grizzly's NIO abstractions to implement a completely non-blocking > client. I'm writing the low-level stuff in Java and I'd really like to build > a Scala layer on top of this, which uses the nice Scala idioms (operators, > case classes, etc...). But I can't write code as fast in Scala as I can in > Java and some of the Java APIs inside Grizzly aren't all that Scala-friendly > and make the code pretty ugly. I figured it would be better to implement a > fairly low-level PB client in Java and flesh out the user-facing API in Scala > and/or Java. > > My question is basically, if I seed this project on GitHub with what I've got > so far, would anyone else be interested in helping complete it? I'm just > working on this after my other Grizzly work, so I can't devote full time to > it. It might take me a little while to implement things like links and > mapreduce. > > I think it shows some real promise because it is completely non-blocking. It > uses Futures and CompletionHandlers to do the dirty work. A Grizzly filter is > responsible for the actual encoding/decoding of protobuf data. Right now, it > will marshall JSON using Jackson if your content-type is set to > "application/json", otherwise it uses JDK serialization to encode the entry > (or just passes a String straight through, of course). > > Since it's a first pass, there is no real attempt to separate the protobuf > stuff from the client. That's a v2 thing. Since I have limited time, I'm > interested in speed to completion of features rather than good-looking and > properly abstracted code. :) > > Thanks! > > Jon Brisbin > http//jbrisbin.com > > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
