Giters

Level / community

Discussion, support and common information for projects in the community.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Any interest in maintaining 'lmdb'?

rvagg opened this issue · comments

commented

I have a query via email asking about taking over the lmdb name in npm. It's currently backed by https://github.com/rvagg/archived-lmdb which I have no interest in maintaining. It was interesting early on but not the most user-friendly data store--potentially the fastest option for many use-cases but requires a lot of tuning and benchmarking to get it just right. There's a lot of interest in using lmdb in Node and there's a few published bindings that have some use.

The original ideal was that lmdb would be fronted by the leveldown interface so users could take advantage of the ecosystem of layering above it. Currently lmdb is archived so "users" can't take advantage of anything and it may as well go to someone who is currently interested in maintaining it and making it worthwhile. But I want to give first-option to @Level/core. Some options include:

  1. Moving archived-lmdb and its npm name here, reviving it and making it usable
  2. Encouraging the individual concerned to do the work here, as a leveldown interface (or something like that0
  3. Just give it up because there's really not much interest or time to do any of the above options.

Thoughts?

commented

I'm +1 in handing it over. I would also ask npm support to do it, as they can make sure that the new owner cannot publish anything on previous semver-major lines (as a security measure).

I would recommend the new maintainer to reach out to this community.

commented

I was the one that reached out to @rvagg about potentially taking over the package name. And yes, I certainly agree with preserving the existing versions. And would be glad to reference these prior works and preserve anything else you feel should be preserved.

As far as leveldown interface, I also recognize the value in consistent APIs. However I think that LMDB has enough distinctives in terms of behavior, transaction management, etc. that a distinct API has been warranted in the LMDB package(s) I have maintained and worked on. I certainly have respect for set of interfaces and implementations that the Level community has built, though.

Let me know if you have any other questions, thanks for the consideration.

commented

Looks like it was handed over; closing.