You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Randall Leeds (Updated) (JIRA)" <ji...@apache.org> on 2011/10/03 23:39:34 UTC

[jira] [Updated] (COUCHDB-1285) Allow configuration of vendor and module version in the welcome message

     [ https://issues.apache.org/jira/browse/COUCHDB-1285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Leeds updated COUCHDB-1285:
-----------------------------------

    Attachment: vendor_and_modules.patch

I think just vendor (not plural) is sufficient and consistent with the way it makes sense to configure.

{"couchdb" : WelcomeMessage,
 "version" : ...,
 "vendor" : {couch_config:get("vendor")}
}

This patch impements the above, takes the "modules section" out of the welcome message, and uses the [modules] section as MFA tuples for secondary supervisors.

1) [modules] provides a place to OTP-ify secondary couch supervisors (I've already done this with couch_update_notifier_sup in this patch).

2) Modules are required to be supervise-able and authors of well-behaved modules can take care to unset any changes the module makes to couch_config if the module is stopped (automatically done if [modules] section is changed).

3) Modules have a start-up hook so that authors need not ship a .ini file if they would rather use couch_config from code at startup. Also, the start-up hook can initialize modules of any complexity and ensure proper supervision.

4) Values from acinclude.m4 are placed into the default.ini template for [vendor] so that it's possible to keep the autotools packaging and change acinclude.m4 to have custom vendor version.

5) Module installations are not automatically made known to clients. Some modules perhaps should not broadcast their presence and those that do should consider doing so at a well known endpoint rather than in the welcome message.

I would suggest establishing a convention for authors to provide their own welcome message/object under /_module/<name>. This path prefix can also provide modules with a place to attach any interface (user or application). This is only convention and no new code. Additionally, it provides a convention for querying for module presence.
                
> Allow configuration of vendor and module version in the welcome message
> -----------------------------------------------------------------------
>
>                 Key: COUCHDB-1285
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1285
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: Jan Lehnardt
>         Attachments: vendor_and_modules.patch, vendor_and_modules_objects.patch
>
>
> The patch below allows to configure vendor and module version information into the GET / welcome message.
> E.g.
>   [vendor]
>   name = refuge
>   version = 2.0.0
>   
>   [modules]
>   geocouch = 1.2.1
> would produce:
>   {"couchdb":"Welcome","version":"1.2.0","refuge":"2.0.0","modules":{"geocouch":"1.2.1"}}
> --
> --- a/src/couchdb/couch_httpd_misc_handlers.erl
> +++ b/src/couchdb/couch_httpd_misc_handlers.erl
> @@ -30,9 +30,23 @@
>  % httpd global handlers
>  
>  handle_welcome_req(#httpd{method='GET'}=Req, WelcomeMessage) ->
> +    Vendor = case couch_config:get("vendor") of
> +      [] -> [];
> +      Vendor1 -> [{
> +        proplists:get_value("name", Vendor1),
> +        ?l2b(proplists:get_value("version", Vendor1))
> +      }]
> +    end,
> +
> +    Modules = lists:map(fun({Key, Value}) ->
> +      {Key, ?l2b(Value)}
> +    end, couch_config:get("modules")),
> +
>      send_json(Req, {[
>          {couchdb, WelcomeMessage},
> -        {version, list_to_binary(couch_server:get_version())}
> +        {version, list_to_binary(couch_server:get_version())}]
> +        ++ Vendor
> +        ++ [{modules, {Modules}}
>      ]});
>  handle_welcome_req(Req, _) ->
>      send_method_not_allowed(Req, "GET,HEAD").
> -- 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira