----- Original Message ----- > Well, you have 2 choices
> 1) Abstract away the fact that your client is async, so you can > implement RiakResponse etc as wrappers around a Future, first call > to a method calls get on the Future > 2) You can require your users to think aysnc and code callbacks > If you do the latter (or both) you might be best extending the > RawClient interface (or just defining a new one (your > RawAsyncClient)) if you re-use stuff like RiakResponse/IRiakObject > etc then it would be awesome and much easier to integrate into the > Basho library. It would be great to offer library users the option > to go async without changing their higher-level code. I think what I'd like to do is both. :) I'll start with a RawAsyncClient that replaces direct object returns with Futures and override that with one that takes a callback. I'll also base the PBC stuff on both IRiakObject and borrow from what's already in the pbc support in the driver, but integrate some Builder abstractions (something I'm doing in-line now). Once that's done, I can implement a version of RawClient that calls get() on everything, so it's fully compatible. But by using as much from the driver as I can, application code should be quite compatible , even on the fully async side. Thanks! Jon Brisbin http//jbrisbin.com > Whichever, get it up on github and we can start playing around with > it! :D > > Thanks! > > > Jon Brisbin > > > http//jbrisbin.com > > > ----- Original Message ----- > > > > From: "Russell Brown" < russell.br...@me.com > > > > > > > To: "Jon Brisbin" < j...@jbrisbin.com > > > > > > > Cc: "riak-users Users" < riak-users@lists.basho.com > > > > > > > Sent: Wednesday, June 22, 2011 2:27:17 AM > > > > > > Subject: Re: Riak async PB client based on Grizzly > > > > > > 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 >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
