Hi, I was doing some work on erlfdb today and I was reminded that we’ve developed a series of Erlang applications that have no dependency on CouchDB on could be generally useful in other Erlang applications. Some examples include:
b64url - NIF for encoding / decoding strings using a url-safe base64 scheme erlfdb - Erlang bindings for FoundationDB ets-lru - a bounded LRU cache using ETS tables as the backing store khash - NIF wrapper around the Kazlib hashing module snappy - NIF wrapper for Google’s snappy compression library There are others as well. Each of these libraries is maintained in its own GitHub repo, prefixed with a CouchDB name, e.g. https://github.com/apache/couchdb-b64url Unlike the main CouchDB repo, we do not enable Issues or Discussions on these repositories. In many cases the project description and documentation is almost non-existent, e.g. for b64url above the description is “Mirror of Apache CouchDB”. I think we could benefit from making these projects more visible. Paul’s jiffy library for JSON processing is a nice counterexample where he's gotten non-trivial contributions from the broader Erlang community by putting a little distance between it and CouchDB. Do others agree? If so, I’ve been thinking about some next steps that would help on that front: - rebar3 compatibility - project READMEs that clarify the app is independent of (but maintained by) CouchDB - activating GH Issues (and maybe even Discussions?) - releases published in Hex? (bit worried about the interaction with ASF release requirements here) - a page in the CouchDB docs that talks a bit about the Erlang internals and catalogs these apps alongside third-party dependencies I suppose there are more dramatic steps one could take as well like renaming the repo, but I think it’d be better to start small. Cheers, Adam
