Github user iilyak commented on a diff in the pull request:
https://github.com/apache/couchdb/pull/309#discussion_r26262786
--- Diff: rel/overlay/etc/default.ini ---
@@ -23,6 +23,7 @@ file_compression = snappy
; and/or more OS page cache hits, but they can also increase overall
response
; time for writes when there are many attachment write requests in
parallel.
attachment_stream_buffer_size = 4096
+db_definitions = [couch_dbs, mem3_dbs, couch_replicator_dbs, cassim_dbs]
--- End diff --
@kxepal Where do you propose to store registered plugins? We need some form
of persistent storage. Considered options are:
1. well known key in application environment.
- Didn't quite work. Due to the requirement that all applications
need to be loaded.
2. configuration file similar to priv/stats_descriptions.cfg.
- It is awkward to scan a filesystem in startup time
3. default.ini
- easiest
None of the options considered support one click install.
I think we have a misconception about the scope. Vendors do compile
`couchdb` locally and include applications they need. They do not use single
click install. Their goal is to plug the features they've implemented into
`couchdb` without changing `couchdb` code. It can be thought of as embedding
`couchdb` into a bigger ecosystem of applications. While you are thinking about
people who want to download `couchdb` and few plugins with additional
functionality they need and run it on their servers. Which requires different
level of expertise. Making downloadable plugins infrastructure is a much bigger
scope in terms of developing, testing and support. I don't think I have
resources to do that alone in a reasonable time frame. Besides this might be
quite complex and rejected by community on this ground.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
