rocks-level implementation

[MeirionHughes]

Just checking to see if anyone has started rocks-level privately before I have a stab? I see @nxtedition @ronag https://github.com/nxtedition/rocks-level seems to have updated their fork to abstract-level, but their fork is significantly ahead (~700 commits).

[ronag]

I have made some good progress but I'm mostly developing for our in-house needs which might not work well for an open-source project. I would recommend you fork mine and continue from there.

[ronag]

It should be fully compatible with abstract-level. Mostly the development style that doesn't fit well with a open-source type package.

[vweevers]

A better starting point is classic-level. Take the minor differences between leveldown and rocksdb, and apply those to a fork of classic-level. That gives us a good base for maintenance, i.e. being able to cherry-pick future commits from classic-level to rocks-level. Otherwise, there's no room for it in the Level org, just based on how many people are available to maintain it.

[ronag]

Yea... classic-level as a base didn't work for me and upstreaming changes was too slow. Another option would be to apply the "improvements" I've made to classic-level and then forking that into a rocks-level.

[vweevers]

@ronag The leveldown-as-a-base strategy has worked well for several years on rocksdb and is the only reason I've been willing to maintain rocksdb (ignoring my current hiatus). The many changes that you've made in your fork, as great as they may be, are not required to achieve abstract-level compatibility.

@MeirionHughes TLDR, you can use ronag's rocks-level (which I reckon is highly optimized, but it will stay in userland) or you can start fresh (which could become an org project and benefit accordingly, but will have to favor compat over raw performance).

[ronag]

@ronag The leveldown-as-a-base strategy has worked well for several years on rocksdb and is the only reason I've been willing to maintain rocksdb (ignoring my current hiatus). The many changes that you've made in your fork, as great as they may be, are not required to achieve abstract-level compatibility.

Yes, didn't mean it as criticism. It just didn't work for me. I think your suggestion is better community-wise.