On 4 August 2010 10:30, Kevin Smith <[email protected]> wrote: > > On Aug 3, 2010, at 8:10 PM, James Sadler wrote: > > <snip> >> >> I'm talking about creating something new >> here, on top of riak_core. My questions are about the feasibility of >> whether I could extend riak_core to be able to handle these >> situations. > > > <snip>
Hi Kevin, Thanks, that's now a lot clearer. I'm really looking forward to the articles on building apps with riak_core. In the meantime, I'll study the code and brush up on my Erlang. Cheers, James. > > If you are truly considering doing this then it is entirely feasible. > riak_core contains the components Riak uses to coordinate its distributed > processing and nothing else. It's better to think of riak_core as a toolkit > than a framework. There are still a number of items you have to write > yourself in order to get a functioning datastore including but not limited to: > > * Persistence -- either reuse an existing Riak backend, like bitcask, or roll > your own. This goes hand-in-hand with writing your own vnodes, too. > * Sibling values -- Riak's object merging logic is specific to the key/value > store so you'd need to roll your own > * Hinted handoff protocol -- riak_core provides the hooks, in the form of > callback functions, for handoff processing. > * Client APIs -- both the HTTP and protocol buffers interfaces are part of > key/value not core > * Fetching/storing/querying -- For now all of this logic is tied to the > operation of the key/value store. You'll need to write your own replacements. > See riak_kv_get_fsm, riak_kv_put_fsm for examples of the kind of code > necessary. > > I hope this helps clarify what's required to build a system on top of > riak_core. > > --Kevin -- James _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
