search

Level / community

Discussion, support and common information for projects in the community.
MIT License
42 stars 15 forks source link

Any interest in maintaining 'lmdb'? #95

Closed rvagg closed 2 years ago

rvagg commented 3 years ago

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?

mcollina commented 3 years ago

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.

kriszyp commented 3 years ago

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.

vweevers commented 2 years ago

Looks like it was handed over; closing.