You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by nickva <gi...@git.apache.org> on 2016/10/05 16:54:29 UTC
[GitHub] couchdb-chttpd pull request #144: Add ability to return "features" list in t...
GitHub user nickva opened a pull request:
https://github.com/apache/couchdb-chttpd/pull/144
Add ability to return "features" list in the server's welcome message.
This could help users quickly discover the presence of an API or mode of
operation.
Jira: COUCHDB-3180
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/cloudant/couchdb-chttpd couchdb-3180-features-chttpd
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/couchdb-chttpd/pull/144.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #144
----
commit 0e2b7510cd06c4667ccfe44ab8720438f49c4d2e
Author: Nick Vatamaniuc <va...@apache.org>
Date: 2016-10-05T16:51:37Z
Add ability to return "features" list in the server's welcome message.
This could help users quickly discover the presence of an API or mode of
operation.
Jira: COUCHDB-3180
----
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@rnewson Updated.
Tried to do features right. Ended up with less code than expected, but not sure if missed an obvious corner case or something of that sort.
Added some tests as suggested. Tests fail on travis as they need the new config API, would have to try it locally with the couch-config PR ... [obligatory multi-repo complaint goes here].
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by rnewson <gi...@git.apache.org>.
Github user rnewson commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
I agree with kxepal that it's odd to create an hardcoded empty list. We've wanted a general feature discovery thing for a while now so let's come up with a way for code to register with this. The patch should include that mechanism even if nothing in couchdb calls it yet, and a test that shows that a registered feature shows up in the welcome message.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@nickva Could couch_epi be used for discovering these features? It looks as good candidate for that role.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@nickva
It's logical issue and it may leads to conflicts. Say, we have a feature FTS (full text search) which could be both provided by couchdb-lucene and dreyfus. Both acts differently, but feature is the same. Both may works together, but from point of client, who process that list it will be undefined behaviour which FTS feature to use.
So semantically, object is better here since we guarantee only one feature presence and we can raise conflicts exceptions with easy.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd pull request #144: Add ability to return a "features" list in...
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/couchdb-chttpd/pull/144
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
Here is what I have for the implementation:
https://github.com/apache/couchdb-config/pull/14
I tried to keep it simple, but probably missed obvious things...
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return "features" list in the serv...
Posted by iilyak <gi...@git.apache.org>.
Github user iilyak commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
+1 after fixing a typo
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by rnewson <gi...@git.apache.org>.
Github user rnewson commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
+1 but see comments on https://github.com/apache/couchdb-config/pull/14 first.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@nickva Ok, thanks. How it will not be abandoned (:
As for replicator I see here case when this list will be not list of strings, but objects, since replicator may provide own set of features like version, preferred mode and else bits. I mean that it would be nice to design this feature well for future needs.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@nickva no, I mean `features` feature (:
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@kxepal oh I see, sorry for confusion :-)
Yeah a list could have duplicates but that's not semantically terrible to say feature_x is present then say it is present again. It is not the same as saying a document with same ID got added to the database. Also a list is easier to build and maintain in Erlang.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
Probably, in this case it's better to have `features` an object of objects rather than list of things. Because we couldn't have any feature mentioned there twice, but would like to have quick and simple way to check feature presence and access it without iteration over whole list (not Erlang case unless we're going to maps soon).
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
Well, anyway, I think this is good discussion for dev@ ML, not here. First step made and that's great! (:
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@kxepal if we have a new feature say geo, we'd add a function it would check of config option or the presence of a plugin.
For example:
```
get_features() ->
Features = [
check_geo_enabled(),
check_other()
],
[Feature || {Feature, true} <- Features].
check_geo_enabled() ->
{<<"geo">>, config:get_boolean("geo_module", "enabled", false)}.
check_other() ->
{<<"other">>, code:which(other_module) =/= non_existing}.
```
Could eventually become a fancier implementation where some components can post their features to a special application or API, and this would read from that.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@nickva How would this features list get filled?
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@kxepal It probably can be used to build the list of features, maybe with some feature discover- ability API extension. Or maybe it can override get_features().
So far I left it simple as a start.
To provide more context for this, for example Cloudant uses something like this for the geo code. Users can tell if it is enabled or not.
We just had another usage example: the new replicator code (you might have seen it in the "next" CouchDB mailing list). It improves a few things, but in doing so it changes the API a bit so docs don't get all the state updates written back to them. This would allow for example for user code to quickly check if the new replicator is loaded (to know not to expect "triggered" states in replication docs). I imagine some might prefer to user one replicator vs the other for a while to maintain backwards compatibility.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
Alright, good points, agree. If it's worth doing, it's worth doing right.
Here is what I came with as first thing:
* Don't add a new application, it would be silly.
* Stick it in config application. It seems like a configuration-y thing.
* 3 new functions. API looks like
- `config:features() -> [<<"feature1">>, <<"feature2">>, ...].`
- `config:feature_enable(<<"feature1">>).`
- `config:feature_disable(<<"feature2">>).`
* Applications enable features and disable them. Then `chttpd` reads list of features from config and shows them in the welcome message.
* Behind the scenes it is really just writing to config "[features]" section a bunch of booleans. With persistence set to `false`.
* Users can directly set "features" in the config file transparently.
The advantage is it doesn't reinvent the world. Takes advantage of config server (so applications can monitor for changes and such if needed).
( Added same comment to https://issues.apache.org/jira/browse/COUCHDB-3180 )
@rnewson I'll give this a try and see what it looks like
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@nickva
> This commit shouldn't prevent it, the comment about the features being a list of binaries is just a suggestion. A feature could be an object as well.
Yea, I see. I just about early things standardization to not fall into legacy hell eventually before it will be too late to change anything.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@kxepal
You mean the new replicator code? It shouldn't be abandoned. You can check out what we have so far: https://github.com/cloudant/couchdb-couch-replicator/tree/63012-scheduler it is not 100% finished, still polishing the API, then will probably be ready for more eyes too look at it.
> As for replicator I see here case when this list will be not list of strings, but objects, since replicator may provide own set of features like version...
Good idea. This commit shouldn't prevent it, the comment about the features being a list of binaries is just a suggestion. A feature could be an object as well.
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-chttpd issue #144: Add ability to return a "features" list in the se...
Posted by nickva <gi...@git.apache.org>.
Github user nickva commented on the issue:
https://github.com/apache/couchdb-chttpd/pull/144
@kxepal
> So semantically, object is better here since we guarantee only one feature presence and we can raise conflicts exceptions with easy.
Can just as easily write code which overwrites a feature object key just as can do lists:usort on the features list before returning. Or if we want server to crash can easily check for `lists:usort(Features) = lists:sort(Features)` before returning the request.
I still don't see having to manage an object as being a lot better than a simple list of labels
---
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 infrastructure@apache.org or file a JIRA ticket
with INFRA.
---