[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13119856#comment-13119856
]
Benjamin Young commented on COUCHDB-1285:
-
Thanks, Randall.
We should also probably consider having a "package" or similar key, so that the
package names can easily show up in Futon--not just vendor names.
[vendor]
name = Cloudant
package = BigCouch
version = 1.3.22
Futon could then easily use vendor.name + vendor.package in the title bar of
_utils for instance and down in the right-hand sidebar area.
Thoughts?
> 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, vendor_only.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
[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_only.patch
Sure thing, Ben.
Here's a version of the patch that only does the vendor bits. I added back the
handling of an empty [vendor] section like Jan had it, just in case.
Default setup shows
{"couchdb":"Welcome","version":"1.3.0a-0dd0168-git","vendor":{"version":"1.3.0a-0dd0168-git","name":"The
Apache Software Foundation"}}
No objections I'll commit this tomorrow.
> 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, vendor_only.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
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13119768#comment-13119768
]
Benjamin Young commented on COUCHDB-1285:
-
Should we consider splitting this ticket? One for vendor object stuff and one
for modules?
This modules approach seems great as it's tied to more useful features than
just version reporting, but it also greatly extends the meaning of this
ticket's title. :)
Great work, Randall.
> 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
[jira] [Commented] (COUCHDB-1301) Add JS helper function for outputing Date-based arrays
[ https://issues.apache.org/jira/browse/COUCHDB-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119742#comment-13119742 ] Benjamin Young commented on COUCHDB-1301: - I'd love to get feedback not only on this specific issue, but also on this idea of a library of common JS functions/patterns that the community finds useful frequently. Having these on hand (ideally with some documentation/reference) would hopefully lower the barrier to entry for new devs looking at how to do what with CouchDB. Thanks for considering this idea, Benjamin -- @bigbluehat byo...@bigbluehat.com > Add JS helper function for outputing Date-based arrays > -- > > Key: COUCHDB-1301 > URL: https://issues.apache.org/jira/browse/COUCHDB-1301 > Project: CouchDB > Issue Type: New Feature >Reporter: Benjamin Young > Labels: views > > I often output Date-based arrays [2011, 9, 3, 7, 14, 10] when building > MapReduce queries. It's such a common pattern, that I'd find it very helpful > to have this built into CouchDB (and ideally JavaScript! ;) ). > I've written up the function to handle this at https://gist.github.com/1259891 > Please consider it for inclusion into the share/server folder, so it can be > available for everyone. It's such a common pattern that I think it makes > sense for it to be part of the core distribution. -- 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
Re: [jira] [Created] (COUCHDB-1301) Add JS helper function for outputing Date-based arrays
I'd love to get feedback not only on this specific issue, but also on this idea of a library of common JS functions/patterns that the community finds useful frequently. Having these on hand (ideally with some documentation/reference) would hopefully lower the barrier to entry for new devs looking at how to do what with CouchDB. Thanks for considering this idea, Benjamin -- @bigbluehat byo...@bigbluehat.com On 10/3/11 7:18 PM, Benjamin Young (Created) (JIRA) wrote: Add JS helper function for outputing Date-based arrays -- Key: COUCHDB-1301 URL: https://issues.apache.org/jira/browse/COUCHDB-1301 Project: CouchDB Issue Type: New Feature Reporter: Benjamin Young I often output Date-based arrays [2011, 9, 3, 7, 14, 10] when building MapReduce queries. It's such a common pattern, that I'd find it very helpful to have this built into CouchDB (and ideally JavaScript! ;) ). I've written up the function to handle this at https://gist.github.com/1259891 Please consider it for inclusion into the share/server folder, so it can be available for everyone. It's such a common pattern that I think it makes sense for it to be part of the core distribution. -- 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
[jira] [Created] (COUCHDB-1301) Add JS helper function for outputing Date-based arrays
Add JS helper function for outputing Date-based arrays -- Key: COUCHDB-1301 URL: https://issues.apache.org/jira/browse/COUCHDB-1301 Project: CouchDB Issue Type: New Feature Reporter: Benjamin Young I often output Date-based arrays [2011, 9, 3, 7, 14, 10] when building MapReduce queries. It's such a common pattern, that I'd find it very helpful to have this built into CouchDB (and ideally JavaScript! ;) ). I've written up the function to handle this at https://gist.github.com/1259891 Please consider it for inclusion into the share/server folder, so it can be available for everyone. It's such a common pattern that I think it makes sense for it to be part of the core distribution. -- 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
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13119670#comment-13119670
]
Randall Leeds commented on COUCHDB-1285:
I also would welcome a version where the module initialization hook returns a
child specification so that it may be a supervisor or a worker and support the
'dynamic' argument in the child specification.
Keep in mind that not every couchdb plugin/module needs to register anything
under [modules]. Only if it needs to link into start/stop lifecycle hooks.
> 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
[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/. 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
Re: CIA.vc notifications in IRC
On 3 Oct 2011, at 16:46, Paul Davis wrote: > On Mon, Oct 3, 2011 at 10:39 AM, Noah Slater wrote: >> >> On 3 Oct 2011, at 16:32, Paul Davis wrote: >> >>> On Mon, Oct 3, 2011 at 10:17 AM, Noah Slater wrote: On 3 Oct 2011, at 16:03, Paul Davis wrote: >> I would avoid writing our own IRC bot at almost any cost. > > What happened to the Noah I used to know? There's a difference between pet projects and robust systems for a serious project. ;) >>> >>> Does that mean you're not volunteering for pager duty? >> >> No. >> >> COUCHDB AR SRS BSNS. > > http://1.bp.blogspot.com/_WpWmksfqx0k/TJOcjd2WxfI/A4I/2EWXgnehF5Q/s1600/06-serious.jpg http://cache.ohinternet.com/images/b/b2/Seriousbusiness2.jpg
Re: CIA.vc notifications in IRC
On Mon, Oct 3, 2011 at 10:39 AM, Noah Slater wrote: > > On 3 Oct 2011, at 16:32, Paul Davis wrote: > >> On Mon, Oct 3, 2011 at 10:17 AM, Noah Slater wrote: >>> >>> On 3 Oct 2011, at 16:03, Paul Davis wrote: >>> > I would avoid writing our own IRC bot at almost any cost. What happened to the Noah I used to know? >>> >>> There's a difference between pet projects and robust systems for a serious >>> project. ;) >> >> Does that mean you're not volunteering for pager duty? > > No. > > COUCHDB AR SRS BSNS. http://1.bp.blogspot.com/_WpWmksfqx0k/TJOcjd2WxfI/A4I/2EWXgnehF5Q/s1600/06-serious.jpg
Re: CIA.vc notifications in IRC
On 3 Oct 2011, at 16:32, Paul Davis wrote: > On Mon, Oct 3, 2011 at 10:17 AM, Noah Slater wrote: >> >> On 3 Oct 2011, at 16:03, Paul Davis wrote: >> I would avoid writing our own IRC bot at almost any cost. >>> >>> What happened to the Noah I used to know? >> >> There's a difference between pet projects and robust systems for a serious >> project. ;) > > Does that mean you're not volunteering for pager duty? No. COUCHDB AR SRS BSNS.
Re: CIA.vc notifications in IRC
On Mon, Oct 3, 2011 at 10:17 AM, Noah Slater wrote: > > On 3 Oct 2011, at 16:03, Paul Davis wrote: > >>> I would avoid writing our own IRC bot at almost any cost. >> >> What happened to the Noah I used to know? > > There's a difference between pet projects and robust systems for a serious > project. ;) Does that mean you're not volunteering for pager duty?
Re: CIA.vc notifications in IRC
On 3 Oct 2011, at 16:03, Paul Davis wrote: >> I would avoid writing our own IRC bot at almost any cost. > > What happened to the Noah I used to know? There's a difference between pet projects and robust systems for a serious project. ;)
Re: CIA.vc notifications in IRC
> I would avoid writing our own IRC bot at almost any cost. What happened to the Noah I used to know?
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13119328#comment-13119328
]
Andrey Somov commented on COUCHDB-1285:
---
+1 to have just one vendor
> 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_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
Re: CIA.vc notifications in IRC
On Monday, October 3, 2011, Noah Slater wrote: > I'd have a chat with the CIA.vc guys, to see what they say. We're obviously not the first people wanting notifications for a Git repository. I would avoid writing our own IRC bot at almost any cost. it's possible for sure. the github cia.vc service works like you described. > > On 3 Oct 2011, at 08:31, Paul Davis wrote: > >> Randall remind me that I haven't implemented IRC notifications for >> commits yet so I started looking at CIA.vc's GIT support. The more I >> look the less I think its a good fit for Git. This is mostly tied to >> the fact that lots of old VCS hooks are written with an assumption of >> "one push is one commit." >> >> So with CIA.vc (unless I'm missing the docs, which includes reading >> the source to the recommended git hook) we have to think about things >> like, one IRC notification per commit, per branch, or per push. IOW, I >> don't see a good way for messages like "davisp updated refname [hash1 >> ... hash2] " type notifications. >> >> Alternatively, I can write a short script that just does the IRC >> notifications which isn't too hard. Its a bit hackish, but we use >> similar things at work and it seems to be more robust than even >> GitHub's IRC bot. >> >> Anyway, input is requested so I know what I should be looking at. > >
Re: CIA.vc notifications in IRC
I'd have a chat with the CIA.vc guys, to see what they say. We're obviously not the first people wanting notifications for a Git repository. I would avoid writing our own IRC bot at almost any cost. On 3 Oct 2011, at 08:31, Paul Davis wrote: > Randall remind me that I haven't implemented IRC notifications for > commits yet so I started looking at CIA.vc's GIT support. The more I > look the less I think its a good fit for Git. This is mostly tied to > the fact that lots of old VCS hooks are written with an assumption of > "one push is one commit." > > So with CIA.vc (unless I'm missing the docs, which includes reading > the source to the recommended git hook) we have to think about things > like, one IRC notification per commit, per branch, or per push. IOW, I > don't see a good way for messages like "davisp updated refname [hash1 > ... hash2] " type notifications. > > Alternatively, I can write a short script that just does the IRC > notifications which isn't too hard. Its a bit hackish, but we use > similar things at work and it seems to be more robust than even > GitHub's IRC bot. > > Anyway, input is requested so I know what I should be looking at.
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13119300#comment-13119300
]
Benjamin Young commented on COUCHDB-1285:
-
@benoit what's the motivation behind a plural "vendors" object/array vs. a
"vendor" key? There's really only ever one originating vendor. There are, of
course, a chain of people responsible for the "shipped" product (which might be
a combination of BigCouch + Refuge + GeoCouch), but the party responsible for
distributing the app would be the single vendor recorded in the .ini they
include with the download.
Additionally, we need to avoid vendor names as keys in the vendor object. Doing
so makes referencing the name of the product much more consistent
(doc.vendor.name), avoids product names being entered again in Futon code, and
allows vendors to use whatever sort of string name they like without developers
having to do anything cumbersome or strange looking to reference the vendor's
key.
My goal is to make this generic and reusable by all the groups out there who
would find value in this [vendor] section being added to the config.
> 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_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
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=13119188#comment-13119188
]
Andrey Somov commented on COUCHDB-1285:
---
>how to register these modules ?
I did not quite catch you. As far as I understand this is a pure configuration
change, which is going to be exposed only via the welcome message.
> 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_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
CIA.vc notifications in IRC
Randall remind me that I haven't implemented IRC notifications for commits yet so I started looking at CIA.vc's GIT support. The more I look the less I think its a good fit for Git. This is mostly tied to the fact that lots of old VCS hooks are written with an assumption of "one push is one commit." So with CIA.vc (unless I'm missing the docs, which includes reading the source to the recommended git hook) we have to think about things like, one IRC notification per commit, per branch, or per push. IOW, I don't see a good way for messages like "davisp updated refname [hash1 ... hash2] " type notifications. Alternatively, I can write a short script that just does the IRC notifications which isn't too hard. Its a bit hackish, but we use similar things at work and it seems to be more robust than even GitHub's IRC bot. Anyway, input is requested so I know what I should be looking at.
