Iterator API

[yrashk]

This change allows applications that need something more controllable than a "blind fold" to iterate over bitcask keydir keys.

[slfritchie]

I don't see a reason not to do this. Opinions @gburd or @justinsheehy or @jonmeredith?

[gburd]

@slfritchie agreed, +1 to merge

[yrashk]

If necessary, I can also add iterator, iterator_next and iterator_release wrappers in bitcask module that will extract keydir out of #bc_state{}

[yrashk]

(since bc_state is effectively opaque)

[slfritchie]

Yurii, the extractors sound good, er, or even necessary. I guess it becomes the user's responsibility to not do anything dumb with that state. You could (in theory) go meddling with the keydir and break things in countless ways. But if that's what you want to do, that's rope that I'm willing to give. Any disagreement, oh Bashonians?

[yrashk]

I am working on wrappers already.

[jonmeredith]

I'd personally like to see the wrappers. Bitcask should present a single-module interface rather than have people digging in the process dictionary and working out the NIF arguments.

(just saw you say you were working on wrappers as I wrote it).

[yrashk]

Added wrappers

[yrashk]

Thoughts? Can we merge this? I would love to be able to use this instead of playing with an opaque structure stored in my process' dictionary...

[justinsheehy]

+1

Merging.