[jira] Resolved: (COUCHDB-1061) More efficient _changes?include_docs=true and _all_docs?include_docs=true
[ https://issues.apache.org/jira/browse/COUCHDB-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Filipe Manana resolved COUCHDB-1061. Resolution: Fixed Applied to trunk, 1.1.x and 1.0.x More efficient _changes?include_docs=true and _all_docs?include_docs=true - Key: COUCHDB-1061 URL: https://issues.apache.org/jira/browse/COUCHDB-1061 Project: CouchDB Issue Type: Improvement Reporter: Filipe Manana Assignee: Filipe Manana Fix For: 1.0.3, 1.1, 1.2 Attachments: COUCHDB-1061-2.patch, COUCHDB-1061-2.patch, COUCHDB-1061.patch When using the changes stream with the option include_docs set to true, after having the #doc_info record of a document, we open the document by its ID instead of using the #doc_info record. This is not optimal since opening the doc by its ID implies traversing the by-id B-Tree to find a #full_doc_info record and to finally convert it into a #doc_info record. The following patch fixes this. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COUCHDB-1032) CouchDB fails to bind to IPv6 address on Windows
[
https://issues.apache.org/jira/browse/COUCHDB-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992986#comment-12992986
]
Dave Cottlehuber commented on COUCHDB-1032:
---
I can't replicate this on 1.0.2. Can you try the following steps build, and
confirm if you still are unable to bind?
I can bind successfully using WinXP SP3 IPv6, CouchDB 1.0.2 from unofficial
build at
https://github.com/downloads/dch/couchdb/setup-couchdb-1.0.2_otp_R14B01_spidermonkey_1.8.5.exe
# update couchdb config
net stop Apache CouchDB
edit local.ini
[httpd]
;port = 5984
;bind_address = 127.0.0.1
bind_address = ::
# install IPv6 - windows XP
netsh interface ipv6 install
netsh interface ipv6 set privacy disabled
# start couchdb service say hallo
net start apache couchdb
curl.exe -v http://\[::1\]:5984
* About to connect() to ::1 port 5984 (#0)
* connected
* Connected to ::1 () port 5984 (#0)
GET / HTTP/1.1
User-Agent: curl/7.21.1 (i386-pc-win32) libcurl/7.21.1
Host: [::1]:5984
Accept: */*
HTTP/1.1 200 OK
Server: CouchDB/1.0.2 (Erlang OTP/R14B)
Date: Thu, 10 Feb 2011 10:35:24 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 40
Cache-Control: must-revalidate
{couchdb:Welcome,version:1.0.2}
* Connection #0 to host ::1 left intact
* Closing connection #0
CouchDB fails to bind to IPv6 address on Windows
Key: COUCHDB-1032
URL: https://issues.apache.org/jira/browse/COUCHDB-1032
Project: CouchDB
Issue Type: Bug
Components: Database Core, HTTP Interface
Affects Versions: 1.0.1
Environment: Windows 7 32bit
couchdb 1.0.1 windows binary installer
Reporter: Alessio Caiazza
Priority: Critical
I'm trying to bind to IPv6 address :: but couchDB didn't start.
I've tried with
bind_address = ::
and with the specific IPv6 address.
# LOG level setted do debug
###
Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0]
Eshell V5.8 (abort with ^G)
1 Apache CouchDB 1.0.1 (LogLevel=debug) is starting.
Configuration Settings [../etc/couchdb/default.ini,
../etc/couchdb/local.ini]:
[admins] ***LINE REMOVED***
[admins] ***LINE REMOVED***
[attachments] compressible_types=text/*, application/javascript,
application/json, application/xml
[attachments] compression_level=8
[couch_httpd_auth] auth_cache_size=50
[couch_httpd_auth] authentication_db=_users
[couch_httpd_auth] authentication_redirect=/_utils/session.html
[couch_httpd_auth] require_valid_user=false
[couch_httpd_auth] ***LINE REMOVED***
[couch_httpd_auth] timeout=600
[couchdb] database_dir=../var/lib/couchdb
[couchdb] delayed_commits=true
[couchdb] max_attachment_chunk_size=4294967296
[couchdb] max_dbs_open=100
[couchdb] max_document_size=4294967296
[couchdb] os_process_timeout=5000
[couchdb] uri_file=../var/lib/couchdb/couch.uri
[couchdb] util_driver_dir=../lib/couch-1.0.1/priv/lib
[couchdb] view_index_dir=../var/lib/couchdb
[daemons] auth_cache={couch_auth_cache, start_link, []}
[daemons] db_update_notifier={couch_db_update_notifier_sup, start_link,
[]}
[daemons] external_manager={couch_external_manager, start_link, []}
[daemons] httpd={couch_httpd, start_link, []}
[daemons] query_servers={couch_query_servers, start_link, []}
[daemons] stats_aggregator={couch_stats_aggregator, start, []}
[daemons] stats_collector={couch_stats_collector, start, []}
[daemons] uuids={couch_uuids, start, []}
[daemons] view_manager={couch_view, start_link, []}
[httpd] allow_jsonp=false
[httpd] authentication_handlers={couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
cookie_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
[httpd] bind_address=::
[httpd] default_handler={couch_httpd_db, handle_request}
[httpd] max_connections=2048
[httpd] port=5984
[httpd] secure_rewrites=true
[httpd] vhost_global_handlers=_utils, _uuids, _session, _oauth, _users
[httpd_db_handlers] _changes={couch_httpd_db, handle_changes_req}
[httpd_db_handlers] _compact={couch_httpd_db, handle_compact_req}
[httpd_db_handlers] _design={couch_httpd_db, handle_design_req}
[httpd_db_handlers] _temp_view={couch_httpd_view, handle_temp_view_req}
[httpd_db_handlers] _view_cleanup={couch_httpd_db,
handle_view_cleanup_req}
[httpd_design_handlers] _info={couch_httpd_db, handle_design_info_req}
[httpd_design_handlers] _list={couch_httpd_show, handle_view_list_req}
[httpd_design_handlers] _rewrite={couch_httpd_rewrite, handle_rewrite_req}
[httpd_design_handlers] _show={couch_httpd_show, handle_doc_show_req}
[httpd_design_handlers] _update={couch_httpd_show,
[jira] Commented: (COUCHDB-1032) CouchDB fails to bind to IPv6 address on Windows
[
https://issues.apache.org/jira/browse/COUCHDB-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12993010#comment-12993010
]
Alessio Caiazza commented on COUCHDB-1032:
--
Fixed in 1.0.2
CouchDB fails to bind to IPv6 address on Windows
Key: COUCHDB-1032
URL: https://issues.apache.org/jira/browse/COUCHDB-1032
Project: CouchDB
Issue Type: Bug
Components: Database Core, HTTP Interface
Affects Versions: 1.0.1
Environment: Windows 7 32bit
couchdb 1.0.1 windows binary installer
Reporter: Alessio Caiazza
Priority: Critical
Fix For: 1.0.2
I'm trying to bind to IPv6 address :: but couchDB didn't start.
I've tried with
bind_address = ::
and with the specific IPv6 address.
# LOG level setted do debug
###
Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0]
Eshell V5.8 (abort with ^G)
1 Apache CouchDB 1.0.1 (LogLevel=debug) is starting.
Configuration Settings [../etc/couchdb/default.ini,
../etc/couchdb/local.ini]:
[admins] ***LINE REMOVED***
[admins] ***LINE REMOVED***
[attachments] compressible_types=text/*, application/javascript,
application/json, application/xml
[attachments] compression_level=8
[couch_httpd_auth] auth_cache_size=50
[couch_httpd_auth] authentication_db=_users
[couch_httpd_auth] authentication_redirect=/_utils/session.html
[couch_httpd_auth] require_valid_user=false
[couch_httpd_auth] ***LINE REMOVED***
[couch_httpd_auth] timeout=600
[couchdb] database_dir=../var/lib/couchdb
[couchdb] delayed_commits=true
[couchdb] max_attachment_chunk_size=4294967296
[couchdb] max_dbs_open=100
[couchdb] max_document_size=4294967296
[couchdb] os_process_timeout=5000
[couchdb] uri_file=../var/lib/couchdb/couch.uri
[couchdb] util_driver_dir=../lib/couch-1.0.1/priv/lib
[couchdb] view_index_dir=../var/lib/couchdb
[daemons] auth_cache={couch_auth_cache, start_link, []}
[daemons] db_update_notifier={couch_db_update_notifier_sup, start_link,
[]}
[daemons] external_manager={couch_external_manager, start_link, []}
[daemons] httpd={couch_httpd, start_link, []}
[daemons] query_servers={couch_query_servers, start_link, []}
[daemons] stats_aggregator={couch_stats_aggregator, start, []}
[daemons] stats_collector={couch_stats_collector, start, []}
[daemons] uuids={couch_uuids, start, []}
[daemons] view_manager={couch_view, start_link, []}
[httpd] allow_jsonp=false
[httpd] authentication_handlers={couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
cookie_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
[httpd] bind_address=::
[httpd] default_handler={couch_httpd_db, handle_request}
[httpd] max_connections=2048
[httpd] port=5984
[httpd] secure_rewrites=true
[httpd] vhost_global_handlers=_utils, _uuids, _session, _oauth, _users
[httpd_db_handlers] _changes={couch_httpd_db, handle_changes_req}
[httpd_db_handlers] _compact={couch_httpd_db, handle_compact_req}
[httpd_db_handlers] _design={couch_httpd_db, handle_design_req}
[httpd_db_handlers] _temp_view={couch_httpd_view, handle_temp_view_req}
[httpd_db_handlers] _view_cleanup={couch_httpd_db,
handle_view_cleanup_req}
[httpd_design_handlers] _info={couch_httpd_db, handle_design_info_req}
[httpd_design_handlers] _list={couch_httpd_show, handle_view_list_req}
[httpd_design_handlers] _rewrite={couch_httpd_rewrite, handle_rewrite_req}
[httpd_design_handlers] _show={couch_httpd_show, handle_doc_show_req}
[httpd_design_handlers] _update={couch_httpd_show, handle_doc_update_req}
[httpd_design_handlers] _view={couch_httpd_view, handle_view_req}
[httpd_global_handlers] /={couch_httpd_misc_handlers, handle_welcome_req,
\Welcome\}
[httpd_global_handlers] _active_tasks={couch_httpd_misc_handlers,
handle_task_status_req}
[httpd_global_handlers] _all_dbs={couch_httpd_misc_handlers,
handle_all_dbs_req}
[httpd_global_handlers] _config={couch_httpd_misc_handlers,
handle_config_req}
[httpd_global_handlers] _log={couch_httpd_misc_handlers, handle_log_req}
[httpd_global_handlers] _oauth={couch_httpd_oauth, handle_oauth_req}
[httpd_global_handlers] _replicate={couch_httpd_misc_handlers,
handle_replicate_req}
[httpd_global_handlers] _restart={couch_httpd_misc_handlers,
handle_restart_req}
[httpd_global_handlers] _session={couch_httpd_auth, handle_session_req}
[httpd_global_handlers] _stats={couch_httpd_stats_handlers,
handle_stats_req}
[httpd_global_handlers] _utils={couch_httpd_misc_handlers,
handle_utils_dir_req, \../share/couchdb/www\}
[httpd_global_handlers] _uuids={couch_httpd_misc_handlers,
[jira] Closed: (COUCHDB-1032) CouchDB fails to bind to IPv6 address on Windows
[
https://issues.apache.org/jira/browse/COUCHDB-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessio Caiazza closed COUCHDB-1032.
Resolution: Fixed
Fix Version/s: 1.0.2
1.0.2 does not suffer this bug.
CouchDB fails to bind to IPv6 address on Windows
Key: COUCHDB-1032
URL: https://issues.apache.org/jira/browse/COUCHDB-1032
Project: CouchDB
Issue Type: Bug
Components: Database Core, HTTP Interface
Affects Versions: 1.0.1
Environment: Windows 7 32bit
couchdb 1.0.1 windows binary installer
Reporter: Alessio Caiazza
Priority: Critical
Fix For: 1.0.2
I'm trying to bind to IPv6 address :: but couchDB didn't start.
I've tried with
bind_address = ::
and with the specific IPv6 address.
# LOG level setted do debug
###
Erlang R14A (erts-5.8) [source] [smp:2:2] [rq:2] [async-threads:0]
Eshell V5.8 (abort with ^G)
1 Apache CouchDB 1.0.1 (LogLevel=debug) is starting.
Configuration Settings [../etc/couchdb/default.ini,
../etc/couchdb/local.ini]:
[admins] ***LINE REMOVED***
[admins] ***LINE REMOVED***
[attachments] compressible_types=text/*, application/javascript,
application/json, application/xml
[attachments] compression_level=8
[couch_httpd_auth] auth_cache_size=50
[couch_httpd_auth] authentication_db=_users
[couch_httpd_auth] authentication_redirect=/_utils/session.html
[couch_httpd_auth] require_valid_user=false
[couch_httpd_auth] ***LINE REMOVED***
[couch_httpd_auth] timeout=600
[couchdb] database_dir=../var/lib/couchdb
[couchdb] delayed_commits=true
[couchdb] max_attachment_chunk_size=4294967296
[couchdb] max_dbs_open=100
[couchdb] max_document_size=4294967296
[couchdb] os_process_timeout=5000
[couchdb] uri_file=../var/lib/couchdb/couch.uri
[couchdb] util_driver_dir=../lib/couch-1.0.1/priv/lib
[couchdb] view_index_dir=../var/lib/couchdb
[daemons] auth_cache={couch_auth_cache, start_link, []}
[daemons] db_update_notifier={couch_db_update_notifier_sup, start_link,
[]}
[daemons] external_manager={couch_external_manager, start_link, []}
[daemons] httpd={couch_httpd, start_link, []}
[daemons] query_servers={couch_query_servers, start_link, []}
[daemons] stats_aggregator={couch_stats_aggregator, start, []}
[daemons] stats_collector={couch_stats_collector, start, []}
[daemons] uuids={couch_uuids, start, []}
[daemons] view_manager={couch_view, start_link, []}
[httpd] allow_jsonp=false
[httpd] authentication_handlers={couch_httpd_oauth,
oauth_authentication_handler}, {couch_httpd_auth,
cookie_authentication_handler}, {couch_httpd_auth,
default_authentication_handler}
[httpd] bind_address=::
[httpd] default_handler={couch_httpd_db, handle_request}
[httpd] max_connections=2048
[httpd] port=5984
[httpd] secure_rewrites=true
[httpd] vhost_global_handlers=_utils, _uuids, _session, _oauth, _users
[httpd_db_handlers] _changes={couch_httpd_db, handle_changes_req}
[httpd_db_handlers] _compact={couch_httpd_db, handle_compact_req}
[httpd_db_handlers] _design={couch_httpd_db, handle_design_req}
[httpd_db_handlers] _temp_view={couch_httpd_view, handle_temp_view_req}
[httpd_db_handlers] _view_cleanup={couch_httpd_db,
handle_view_cleanup_req}
[httpd_design_handlers] _info={couch_httpd_db, handle_design_info_req}
[httpd_design_handlers] _list={couch_httpd_show, handle_view_list_req}
[httpd_design_handlers] _rewrite={couch_httpd_rewrite, handle_rewrite_req}
[httpd_design_handlers] _show={couch_httpd_show, handle_doc_show_req}
[httpd_design_handlers] _update={couch_httpd_show, handle_doc_update_req}
[httpd_design_handlers] _view={couch_httpd_view, handle_view_req}
[httpd_global_handlers] /={couch_httpd_misc_handlers, handle_welcome_req,
\Welcome\}
[httpd_global_handlers] _active_tasks={couch_httpd_misc_handlers,
handle_task_status_req}
[httpd_global_handlers] _all_dbs={couch_httpd_misc_handlers,
handle_all_dbs_req}
[httpd_global_handlers] _config={couch_httpd_misc_handlers,
handle_config_req}
[httpd_global_handlers] _log={couch_httpd_misc_handlers, handle_log_req}
[httpd_global_handlers] _oauth={couch_httpd_oauth, handle_oauth_req}
[httpd_global_handlers] _replicate={couch_httpd_misc_handlers,
handle_replicate_req}
[httpd_global_handlers] _restart={couch_httpd_misc_handlers,
handle_restart_req}
[httpd_global_handlers] _session={couch_httpd_auth, handle_session_req}
[httpd_global_handlers] _stats={couch_httpd_stats_handlers,
handle_stats_req}
[httpd_global_handlers] _utils={couch_httpd_misc_handlers,
handle_utils_dir_req, \../share/couchdb/www\}
[httpd_global_handlers]
Re: roadmap
On Tue, Feb 8, 2011 at 11:37 AM, Robert Newson robert.new...@gmail.com wrote: You're absolutely right. 1.0.2 was ready to go quite some time ago but several bugs were found as we were releasing. We decided, as a team, that we couldn't ship with the bugs that were found, so we elected to fix them and delay the release. I think that was the right decision. We should only release when we feel the software is ready, not when some ultimately arbitrary day looms. I completely agree here: there should be no arbitrary release dates. However, I'm also in favor of increasing the frequency of minor point releases. Node.js is really inspiring in this area, with new minor point releases coming out every week or so (ooh, and 0.4.0 just got released 6 hours ago!). I know the process for an Apache project has more overhead, we don't have a BDFL, and the older community may not appreciate a release cycle that's quite so frantic (interpret that as you like), but there's still something to be learned from the rapid development and enthusiastic community around Node. B. On Tue, Feb 8, 2011 at 4:32 PM, Noah Slater nsla...@apache.org wrote: On 8 Feb 2011, at 16:14, Dirkjan Ochtman wrote: Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I need someone else to weigh in on this, but I believe the reason was because of a few critical bugs that were being worked on. And not, as you suggest, because we were suffering from a Just One More Thing problem. I'd really need Jan or Chris to comment though as I use them as a conduit for judging this stuff.
Re: roadmap
On 10 Feb 2011, at 17:29, Gabriel Farrell wrote: On Tue, Feb 8, 2011 at 11:37 AM, Robert Newson robert.new...@gmail.com wrote: You're absolutely right. 1.0.2 was ready to go quite some time ago but several bugs were found as we were releasing. We decided, as a team, that we couldn't ship with the bugs that were found, so we elected to fix them and delay the release. I think that was the right decision. We should only release when we feel the software is ready, not when some ultimately arbitrary day looms. I completely agree here: there should be no arbitrary release dates. However, I'm also in favor of increasing the frequency of minor point releases. Node.js is really inspiring in this area, with new minor point releases coming out every week or so (ooh, and 0.4.0 just got released 6 hours ago!). I know the process for an Apache project has more overhead, we don't have a BDFL, and the older community may not appreciate a release cycle that's quite so frantic (interpret that as you like), but there's still something to be learned from the rapid development and enthusiastic community around Node. Yup, I totally agree with node showing amazing momentum. But they do have the luxury of being able to break backwards compatibility with any release, really, and we don't have that :) — I think the 1.0.2 time frame was an outlier and that we are in pretty good shape to push maintenance releases quickly, if needed. — Now we only need to demonstrate that :) Cheers Jan -- B. On Tue, Feb 8, 2011 at 4:32 PM, Noah Slater nsla...@apache.org wrote: On 8 Feb 2011, at 16:14, Dirkjan Ochtman wrote: Still, the problem I have is that it seems like there is a tendency to make releases large; it seems like there's little control against devs wanting to add their one more thing. Particularly for bugfix releases; from 1.0.1 it took almost 6 months for 1.0.2 to get released. In between, there were a little under 100 revisions on the 1.0.x branch, presumably most of those fixing bugs users could actually run into. It seems valuable to me if the community could have gotten some of these fixes sooner. I need someone else to weigh in on this, but I believe the reason was because of a few critical bugs that were being worked on. And not, as you suggest, because we were suffering from a Just One More Thing problem. I'd really need Jan or Chris to comment though as I use them as a conduit for judging this stuff.
[jira] Updated: (COUCHDB-984) Animated spinner icon has glitch
[ https://issues.apache.org/jira/browse/COUCHDB-984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Vander Wilt updated COUCHDB-984: --- Attachment: spinner33-main_page.gif spinner6b-upload_dialog.gif spinner55-compromise.gif I'm uploading three files: spinner33-main_page.gif is matched to the main page top bar color. spinner6b-upload_dialog.gif is matched to the #6B6B6B bar in the upload dialog (its color is #666 but also 50% transparent). spinner55-compromise.gif has been exported on a #55 matte, and looks average in both dialogs. Ideally each page would use the right GIF, but you could also just replace images/spinner.gif with spinner55-compromise.gif for an okayish presentation (it will look fuzzy in the main page and have a slight dark fringe in the upload dialog). For future reference: What I did was add an invert filter layer to the Panic PSD to make it whiter instead of blacker, and then set the matte color in the Save for Web dialog. Animated spinner icon has glitch Key: COUCHDB-984 URL: https://issues.apache.org/jira/browse/COUCHDB-984 Project: CouchDB Issue Type: Bug Components: Futon Environment: any Reporter: Nathan Vander Wilt Assignee: Paul Joseph Davis Priority: Minor Fix For: 1.0.2 Attachments: 16x16-Spinner.gif, spinner33-main_page.gif, spinner55-compromise.gif, spinner6b-upload_dialog.gif Original Estimate: 0.5h Remaining Estimate: 0.5h Futon's progress spinner icon found in /share/couchdb/www/image/spinner.gif (used when uploading files and perhaps elsewhere) suffers from the glitch described at http://www.panic.com/blog/2010/10/spinner-rage/, where the fifth frame of the animation flashes more darkly than the others. The Panic post on this issue provides a fixed version of the spinner, but it is a Photoshop file: http://panic.com/blog/wp-content/files/16x16%20Spinner.psd.zip This simply needs to be re-exported by someone with a copy of Adobe's software. (I have a LazyTwitter out on this, otherwise next week I can pester the designers at work for a favor.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
February Boston Couch Hack
Greetings, When: 5:30pm on February 17th Where: Bocoup Loft (http://loft.bocoup.com) Food: Pizza and beer sponsored by Cloudant (http://www.cloudant.com) Link: https://bocoup.eventwax.com/couchdb-hack-night-february-2011 Cost: FREE A bunch of Boston Couchers are going to meet at Bocoup to hack CouchDB. Join the Boston CouchDB user group to hack on a group project and talk Couch. CouchDB experts and new users welcome! We are going to be voting in advance on what we should work on as a group. Please Cast your votes here and sign up at https://bocoup.eventwax.com/couchdb-hack-night-february-2011 We look forward to seeing you there. Cheers, -- Sam Bisbee www.sbisbee.com
Re: roadmap
Hi, On 9 Feb 2011, at 08:29, Benoit Chesneau wrote: It's not clear to me that couchdb would benefit by bundling clustering and search. Lucene has an approach that might work for us, namely where there's an explicit core project, with a number of supplementary parts. Releases are aligned for all of them, but the separation is pretty clear. I agree, wasn't speaking to make a bundle, but we could have official plugins supported by the apache project like hadoop or solr have. Something like Apache Extras might be of interest (though afaict it's really just a branded google code). https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches At the very least I think specific couchapps (implementations of wikis, blogs etc) should be encouraged to go there for hosting. I'm not sure couchdb-lucene, couchapp itself or geocouch (and other future plugins) are entirely suitable, but I guess it depends on how apache extras evolve over time. Cheers Simon
Re: roadmap
Hi, - a really good plugin story (geocouch, lucene search, easy to compile against couchdb sources) I don't know how possible this is (I can think of a number of issues without trying) but having these plugins uploadable into a database in a similar manner to views would be super sweet. It would mean you could find a vanilla couch hosting company and tailor it to your databases needs directly over HTTP. Cheers Simon
Re: roadmap
Randall Leeds wrote: My priorities are: - a really good embedding story (android, desktop apps, couchbase, etc ...) ... - a really good build story (particularly android, windows) Having recently worked with the Android port (see build instructions on wiki -- soon to be updated improved) we might be able to help with these things. We're releasing a collaborative mobile data collection product in the next few weeks that uses Open Data Kit technology and CouchDB for persistence and synchronization. More to come on this, obviously. Cheers, Matt -- Matt Adams Radical Dynamic www.radicaldynamic.com
