couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Randall Leeds (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (COUCHDB-1285) Allow configuration of vendor and module version in the welcome message
Date Mon, 03 Oct 2011 21:39:34 GMT

     [ 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

        

Mime
View raw message