We have a few projects where we make use of PouchDB’s different adapters (level and http in our case) to run software in different environments. We also use couchdb-bootstrap, which doesn’t work with PouchDB instances itself, but only a CouchDB server.
In theory, would this project (and the sub-projects it is built from) accept a set of PRs that add support for PouchDB instances instead of just URLs that are passed to nano?
A first implementation could do if/else switches at the various places where they are needed, but one could argue that once you use PouchDB and since it can use a CouchDB URL using the http adapter, wouldn’t it make sense to just stop using nano here. This question doesn’t ask to do the full replacement, just additional support for bootstrapping a PouchDB instance, but a wholesale transition might be less effort.
It’d be totally fine to say “no, out of scope” :)
@jo
We have a few projects where we make use of PouchDB’s different adapters (level and http in our case) to run software in different environments. We also use couchdb-bootstrap, which doesn’t work with PouchDB instances itself, but only a CouchDB server.
In theory, would this project (and the sub-projects it is built from) accept a set of PRs that add support for PouchDB instances instead of just URLs that are passed to nano?
A first implementation could do if/else switches at the various places where they are needed, but one could argue that once you use PouchDB and since it can use a CouchDB URL using the http adapter, wouldn’t it make sense to just stop using nano here. This question doesn’t ask to do the full replacement, just additional support for bootstrapping a PouchDB instance, but a wholesale transition might be less effort.
It’d be totally fine to say “no, out of scope” :)
@jo