Re: Updating the CouchDB roadmap
> Thanks for reminding me that I should set _all_dbs to hide dbs the > curertn user can't read if that doesn't incur much additional > overhead. I think that it will incur a huge overhead, if there are a large number of databases and the reader rights are stored within the databases themselves. It'll have to open and read every single database file on disk, even if the user only has access to one. Storing the rights within the user record avoids this problem completely.
Re: Updating the CouchDB roadmap
On Mon, Jan 25, 2010 at 1:14 AM, Brian Candler wrote: > On Sun, Jan 24, 2010 at 09:33:02PM -0800, Chris Anderson wrote: >> To round out this list, I think >> >> * Reader ACLs > ... >> >> look like they will make it into 0.11. > > That's the jchris/readeracl branch presumably? > > I was hoping to turn my counter-proposal(*) into code, but I've not had any > time to do so unfortunately. > > Regards, > > Brian. > > (*) which was, in summary: > > 1. user record has roles like "foo:_reader" or ["foo","_reader"] > > 2. _anon user has roles of ":_reader" for all public databases > > 3. you can read database foo only if you have one of > "foo:_reader", "foo:_admin", "_reader" or "_admin" roles > > 4. /_all_dbs lists only those databases to which you or _anon have read access > (but shows every database if you have _reader or _admin roles) Thanks for reminding me that I should set _all_dbs to hide dbs the curertn user can't read if that doesn't incur much additional overhead. Also, I plan to put a Futon interface on the reader and admin lists. And, the security object still needs work, to round out the capability set to be something like what you describe here. > > 5. userdb validate_doc_update allows someone with "foo:_admin" to add and > remove roles foo:*. Also "foo:_manager" to add and remove roles foo:* > apart from foo:_admin > -- Chris Anderson http://jchrisa.net http://couch.io
Re: Updating the CouchDB roadmap
On Sun, Jan 24, 2010 at 09:33:02PM -0800, Chris Anderson wrote: > To round out this list, I think > > * Reader ACLs ... > > look like they will make it into 0.11. That's the jchris/readeracl branch presumably? I was hoping to turn my counter-proposal(*) into code, but I've not had any time to do so unfortunately. Regards, Brian. (*) which was, in summary: 1. user record has roles like "foo:_reader" or ["foo","_reader"] 2. _anon user has roles of ":_reader" for all public databases 3. you can read database foo only if you have one of "foo:_reader", "foo:_admin", "_reader" or "_admin" roles 4. /_all_dbs lists only those databases to which you or _anon have read access (but shows every database if you have _reader or _admin roles) 5. userdb validate_doc_update allows someone with "foo:_admin" to add and remove roles foo:*. Also "foo:_manager" to add and remove roles foo:* apart from foo:_admin
Re: Updating the CouchDB roadmap
On Sun, Jan 24, 2010 at 5:33 AM, Dirkjan Ochtman wrote:
> On Fri, Dec 18, 2009 at 20:30, Damien Katz wrote:
>> I think we should set a hard date of Feb 1. for feature freeze, 0.11.0 is
>> the last new feature release.
>
> Did this ever turn into some kind of consensus, or is there no idea
> yet about a 0.11 release time frame?
>
I've been shooting for Feb 1st, although I admit there are things I'd
like to see in 0.11 that don't seem close right now:
* Replicator options like by-docid and copy-view
* A global or db config level companion to Benoit's _rewrite work
* An upgrade of the POST {"keys":[...]} view query API to be more
flexible like: POST {"queries":[{"startkey":"foo",
"limit":3},{"starkey":"rox","limit":5}]
There are some non-feature things that I plan to work on in the run up
to 1.0 (after 0.11):
* bcrypt for cookies and password hashing
* couchjs --enable-httpd to avoid sandbox jumping
To round out this list, I think
* Reader ACLs
* Benoit's _rewrite
look like they will make it into 0.11.
(I'm not trying to tell anyone else what's important -- these are just
the things I'm working on or thinking about.)
There may be more, especially if people can corner committers and get
them to evaluate patches that have been lingering.
Chris
> Cheers,
>
> Dirkjan
>
--
Chris Anderson
http://jchrisa.net
http://couch.io
Re: Updating the CouchDB roadmap
On Fri, Dec 18, 2009 at 20:30, Damien Katz wrote: > I think we should set a hard date of Feb 1. for feature freeze, 0.11.0 is the > last new feature release. Did this ever turn into some kind of consensus, or is there no idea yet about a 0.11 release time frame? Cheers, Dirkjan
Re: Updating the CouchDB roadmap
+1 on map/reduce chaining. Sorting by sums at the database level instead of a middle tier would be greatly desired and this would get it done. On Tue, Dec 8, 2009 at 4:48 AM, wrote: > Quoting Noah Slater : > >> As part of the release procedure, this is a request to update the roadmap >> document: >> Please comment on what should be added, and what should be removed. >> > > What I would like to see is "map/reduce chaining", as this really would > blow away most limitations currently imposed by couchdb. A good example for > this would be "get the 10 most popular items from a tag cloud". > > Of course, this also might affect efficiency, as every layer of > map/reducing imposes housekeeping and update costs. > > Cheers, > Kosta > > > -- Martin Murphy Whiteboard-it (205) 910-0720
Re: Updating the CouchDB roadmap
On Thu, Dec 3, 2009 at 8:29 PM, Noah Slater wrote: > Hey, > > As part of the release procedure, this is a request to update the roadmap > document: > > http://couchdb.apache.org/roadmap.html > > Please comment on what should be added, and what should be removed. > > After a we reach consensus, I will update the roadmap. > > Thanks, > > Noah This a quick summary of what have been proposed on this thread. If I forgot one, sorry, and don't hesitate to update :) I'm not sure all of this is in jira. But maybe once they are, we could extract a roadmap from it ? *) New tasks: - Support for compressed attachments - authorization per database - a global notification handler which would allow an indexer (or anything else) to listen changes without opening a connection per db. Some work started here - Better RFC 2616 compliance: some work started, couchdb webmachine branch on github and other commits - Windows support for compaction - design doc refactoring: work started by jchris - Account's tab for Futon *) Old tasks that could be removed from the roadmap : - Continuous replication - Pure tail-append storage - Update API to parse client requests in JavaScript - Cookie authentication support - Windows build supports Date for 0.11: 1/02/20010 - benoit
Re: Updating the CouchDB roadmap
An updated (and no longer breaking 4 test cases) patch for storing compressed attachments was added to tickets 583 and 437. cheers On Sat, Dec 19, 2009 at 8:46 AM, Filipe David Manana wrote: > After rev 891077 (ticket 558, md5 integrity check) I need to update that > patch for storing gzip compressed attachments. > The md5 calculated by couch_stream corresponds to the md5 of the gzipped > content, therefore not matching the attachment content sent by the client > for those attachments having a mime type listed in the additional config > file. > > I'll be fixing this, adding a config option for the compression level and > do the necessary modifications on the existing test cases. A new patch will > be coming soon :) > > cheers > > > On Fri, Dec 18, 2009 at 8:31 PM, Damien Katz wrote: > >> FYI, I haven't looked at this patch's code, but I like it's concepts and I >> hope of the other committers will have a chance to look at it soon and work >> out any issues to get it checked into trunk. If not I eventually will get >> around to it, but I can't promise when. >> >> -Damien >> >> >> On Dec 9, 2009, at 8:07 AM, Filipe David Manana wrote: >> >> > that's ticket 583 - https://issues.apache.org/jira/browse/COUCHDB-583 >> > >> > The ticket's title is no longer fair. One of the last comments >> > mentions the possibility of storing attachments in gzip compressed >> > form (suggestion from Damien). >> > I submitted a patch for that feature yesterday. >> > >> > cheers >> > >> > On Fri, Dec 4, 2009 at 7:17 PM, Robert Newson >> wrote: >> >> Support for compressed attachments? I think there's a ticket for it, >> >> but the basic idea is to support Accept-Encoding/Content-Encoding form >> >> the client and store the attachment with compression (and >> >> decompressing on demand). >> >> >> >> A bulk insertion endpoint that included attachments (without base64 >> >> inflation) would also be nice. >> >> >> >> On Fri, Dec 4, 2009 at 5:55 PM, Dirkjan Ochtman >> wrote: >> >>> On Fri, Dec 4, 2009 at 18:32, Noah Slater >> wrote: >> Hey, does anyone want to start the discussion off? >> >>> >> >>> Question from one of those trailing around on actual releases, that >> >>> may help getting started: what big-ticket features are in trunk, but >> >>> not 0.10.1? >> >>> >> >>> Cheers, >> >>> >> >>> Dirkjan >> >>> >> >> >> > >> > >> > >> > -- >> > Filipe David Manana, >> > fdman...@gmail.com >> > PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B >> > >> > "Reasonable men adapt themselves to the world. >> > Unreasonable men adapt the world to themselves. >> > That's why all progress depends on unreasonable men." >> >> > > > -- > Filipe David Manana, > fdman...@gmail.com > PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men." > > -- Filipe David Manana, fdman...@gmail.com PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Re: Updating the CouchDB roadmap
On Fri, Dec 18, 2009 at 5:02 PM, Paul Davis wrote: > > I'm not really a fan of roadmaps. We get new features when people > write them. Everyone has the ability to write code, submit it and get > a new feature. I can't tell you what feature you're going to write, so > why would I tell everyone else that I expect you to write a given > feature? > > Granted, I would be perfectly happy referring to versions by sha1 so > maybe I'm a bit crazy. > > HTH, > Paul Davis > Well roadmap in a sense would allow everyone to know who working on what. Or if not who, what is the work in progress/planned. Maybe more than a roadmap we can put a todo list and at a time extract some items done to make a release ? - benoit
Re: Updating the CouchDB roadmap
On Sat, Dec 19, 2009 at 9:08 AM, Chris Anderson wrote: > On Fri, Dec 18, 2009 at 9:02 AM, Noah Slater wrote: >> >> On 18 Dec 2009, at 16:45, Dirkjan Ochtman wrote: >> >>> That said, it's perfectly alright if there's no roadmap at all, I'm >>> just surprised by the lack of thoughts from the core developers (who >>> are usually the ones to have these ideas) in this thread. >> >> Three of the core developers have been busy attending to real life for the >> last few weeks. :) > > Heh, > > Mostly I've been dealing with real life by buckling down and writing code. > > I wrote up my ideas for 0.11 / 1.0 in this thread Nov 1st: > > http://mail-archives.apache.org/mod_mbox/couchdb-dev/200911.mbox/%3ce282921e0911011048sec6a907xbeac06651ae2c...@mail.gmail.com%3e > > Re-reading it they are still features I'm interested in, although I'm > much less ambitious now. What I'd really like to see for 0.11: > > Account's tab for Futon: > There's no reason app developers should have to write user account > code or login/logout code. Users should just be able to log in and out > of CouchDB (and sign up for accounts) via something like a Futon page > that ships with the db. The userCtx is already available to Ajax apps > via /_session so once we have a reliable way to log in and out this > will be useful. > Maybe we could also make the auth really useful when you don't access to CouchDB behind a proxy. My plan about this is : - having authentification a little more modular than it is : cascading across authentification modules and also add authentification via a script - authorization: having a way to protect read/write(so delete too) on a db for a list of users or roles - Protect access to the user database. Having it readable by public isn't good for security purpose. Regardless of the length of the key or the algorithm used, there will be a time where it isn't enough. Imo we should hide access to this db behind an api. > Design Doc Refactor: > I've been heads down working on this patch in my spare time for the > last 3 weeks. It is 90% a pure refactor (cleanup code not add new > features.) It is nearing completion. This will change the query server > protocol but not the HTTP API. You can look at what I've got here: > http://github.com/jchris/couchdb/tree/ddoc-qs What will be the changes in protocol ? > > Query Server Security: > I haven't started on this yet but my plan is just to work from > http://github.com/rcoder/couchdb/commits/master to make it more clear > when the curl bindings are available to the JS sandbox. If anyone will > pick this up and run with it I will jump for joy. > I failed to find the relation with security :) Isn't the point of this fork to add an http client ? - benoit
Re: Updating the CouchDB roadmap
On Fri, Dec 18, 2009 at 9:02 AM, Noah Slater wrote: > > On 18 Dec 2009, at 16:45, Dirkjan Ochtman wrote: > >> That said, it's perfectly alright if there's no roadmap at all, I'm >> just surprised by the lack of thoughts from the core developers (who >> are usually the ones to have these ideas) in this thread. > > Three of the core developers have been busy attending to real life for the > last few weeks. :) Heh, Mostly I've been dealing with real life by buckling down and writing code. I wrote up my ideas for 0.11 / 1.0 in this thread Nov 1st: http://mail-archives.apache.org/mod_mbox/couchdb-dev/200911.mbox/%3ce282921e0911011048sec6a907xbeac06651ae2c...@mail.gmail.com%3e Re-reading it they are still features I'm interested in, although I'm much less ambitious now. What I'd really like to see for 0.11: Account's tab for Futon: There's no reason app developers should have to write user account code or login/logout code. Users should just be able to log in and out of CouchDB (and sign up for accounts) via something like a Futon page that ships with the db. The userCtx is already available to Ajax apps via /_session so once we have a reliable way to log in and out this will be useful. Design Doc Refactor: I've been heads down working on this patch in my spare time for the last 3 weeks. It is 90% a pure refactor (cleanup code not add new features.) It is nearing completion. This will change the query server protocol but not the HTTP API. You can look at what I've got here: http://github.com/jchris/couchdb/tree/ddoc-qs Query Server Security: I haven't started on this yet but my plan is just to work from http://github.com/rcoder/couchdb/commits/master to make it more clear when the curl bindings are available to the JS sandbox. If anyone will pick this up and run with it I will jump for joy. I hope that helps make it more clear what I am interested in pursuing. Chris -- Chris Anderson http://jchrisa.net http://couch.io
Re: Updating the CouchDB roadmap
After rev 891077 (ticket 558, md5 integrity check) I need to update that patch for storing gzip compressed attachments. The md5 calculated by couch_stream corresponds to the md5 of the gzipped content, therefore not matching the attachment content sent by the client for those attachments having a mime type listed in the additional config file. I'll be fixing this, adding a config option for the compression level and do the necessary modifications on the existing test cases. A new patch will be coming soon :) cheers On Fri, Dec 18, 2009 at 8:31 PM, Damien Katz wrote: > FYI, I haven't looked at this patch's code, but I like it's concepts and I > hope of the other committers will have a chance to look at it soon and work > out any issues to get it checked into trunk. If not I eventually will get > around to it, but I can't promise when. > > -Damien > > > On Dec 9, 2009, at 8:07 AM, Filipe David Manana wrote: > > > that's ticket 583 - https://issues.apache.org/jira/browse/COUCHDB-583 > > > > The ticket's title is no longer fair. One of the last comments > > mentions the possibility of storing attachments in gzip compressed > > form (suggestion from Damien). > > I submitted a patch for that feature yesterday. > > > > cheers > > > > On Fri, Dec 4, 2009 at 7:17 PM, Robert Newson > wrote: > >> Support for compressed attachments? I think there's a ticket for it, > >> but the basic idea is to support Accept-Encoding/Content-Encoding form > >> the client and store the attachment with compression (and > >> decompressing on demand). > >> > >> A bulk insertion endpoint that included attachments (without base64 > >> inflation) would also be nice. > >> > >> On Fri, Dec 4, 2009 at 5:55 PM, Dirkjan Ochtman > wrote: > >>> On Fri, Dec 4, 2009 at 18:32, Noah Slater > wrote: > Hey, does anyone want to start the discussion off? > >>> > >>> Question from one of those trailing around on actual releases, that > >>> may help getting started: what big-ticket features are in trunk, but > >>> not 0.10.1? > >>> > >>> Cheers, > >>> > >>> Dirkjan > >>> > >> > > > > > > > > -- > > Filipe David Manana, > > fdman...@gmail.com > > PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B > > > > "Reasonable men adapt themselves to the world. > > Unreasonable men adapt the world to themselves. > > That's why all progress depends on unreasonable men." > > -- Filipe David Manana, fdman...@gmail.com PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Re: Updating the CouchDB roadmap
FYI, I haven't looked at this patch's code, but I like it's concepts and I hope of the other committers will have a chance to look at it soon and work out any issues to get it checked into trunk. If not I eventually will get around to it, but I can't promise when. -Damien On Dec 9, 2009, at 8:07 AM, Filipe David Manana wrote: > that's ticket 583 - https://issues.apache.org/jira/browse/COUCHDB-583 > > The ticket's title is no longer fair. One of the last comments > mentions the possibility of storing attachments in gzip compressed > form (suggestion from Damien). > I submitted a patch for that feature yesterday. > > cheers > > On Fri, Dec 4, 2009 at 7:17 PM, Robert Newson wrote: >> Support for compressed attachments? I think there's a ticket for it, >> but the basic idea is to support Accept-Encoding/Content-Encoding form >> the client and store the attachment with compression (and >> decompressing on demand). >> >> A bulk insertion endpoint that included attachments (without base64 >> inflation) would also be nice. >> >> On Fri, Dec 4, 2009 at 5:55 PM, Dirkjan Ochtman >> wrote: >>> On Fri, Dec 4, 2009 at 18:32, Noah Slater wrote: Hey, does anyone want to start the discussion off? >>> >>> Question from one of those trailing around on actual releases, that >>> may help getting started: what big-ticket features are in trunk, but >>> not 0.10.1? >>> >>> Cheers, >>> >>> Dirkjan >>> >> > > > > -- > Filipe David Manana, > fdman...@gmail.com > PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B > > "Reasonable men adapt themselves to the world. > Unreasonable men adapt the world to themselves. > That's why all progress depends on unreasonable men."
Re: Updating the CouchDB roadmap
Apologies for not replying, I have a lot of stuff going on right. For 1.0 features, I only want a few more enhancements to continuous replication (they might already be there) and full windows support. I think we should set a hard date of Feb 1. for feature freeze, 0.11.0 is the last new feature release. Then after that, all new code is for stabilization until we hit 1.0. There will be exceptions some features, and we'll vote on them as they come up. But generally the rules should be post-0.11.0, no new features. 1.0 isn't the end of the line for your desired features though, While 1.0.x is for bug fixes , 1.1, 1.2 etc can have new stuff after a beta period, etc. That's my take on the roadmap. -Damien On Dec 18, 2009, at 7:58 AM, Robert Dionne wrote: > I sort of agree with you, but in all fairness some of the core programmers > have weighed in. > > To repeat my earlier post, I think it's a good time to put some stakes in the > ground with respect to direction. I'm sure there are a number of parties > interested in extending and making use of the internals and a lot has been > discussed in terms of what could be done. A roadmap would be nice, especially > since there is growing corporate support, a key selling point for CouchDB. > > > > > On Dec 18, 2009, at 2:39 AM, Dirkjan Ochtman wrote: > >> It seems weird that none of the core developers have bothered to write >> up some of their ideas here, for ten days running now. I understand >> you're all busy with Relaxed, but it doesn't have to take so long, >> does it? IMO it would be nice to have some kind of idea of where >> CouchDB is going and/or what will be in the next release. >> >> Cheers, >> >> Dirkjan >
Re: Updating the CouchDB roadmap
On 18 Dec 2009, at 17:37, Robert Newson wrote: > Jira does build a roadmap for you, but it depends on you filing > bugs/tasks and assigning them as "fix for ". I'm not sure we > all can add new versions (that should be locked down if it's not > already), but that's how roadmaps are handled in jira. Only me and the JIRA admins can add new versions.
Re: Updating the CouchDB roadmap
Jira does build a roadmap for you, but it depends on you filing bugs/tasks and assigning them as "fix for ". I'm not sure we all can add new versions (that should be locked down if it's not already), but that's how roadmaps are handled in jira. B. On Fri, Dec 18, 2009 at 5:10 PM, Paul Davis wrote: > Link might be handy: > > http://forrest.apache.org/forrest-issues.html > > On Fri, Dec 18, 2009 at 12:09 PM, Paul Davis > wrote: >> On Fri, Dec 18, 2009 at 12:05 PM, Noah Slater wrote: >>> Hey, >>> >>> Does JIRA have a page what we could use as the roadmap? >>> >>> That would have the added advantage of updating itself automatically as we >>> edited tickets. >>> >>> I found the roadmap tab from the main CouchDB page, but it doesn't have any >>> tickets for post 0.10 on it. >>> >>> Thoughts? >>> >>> Thanks, >>> >>> Noah >> >> There was that one page that listed tickets in a format that you said >> you were going to include in the release procedure. That's about all I >> can think of other than saving a query which isn't nearly as awesome. >> >> There's also an example from the Apache Forrest site [1] that lists >> open issues for the next release on their site which might also be an >> interesting approach. >> >> HTH, >> Paul Davis >> >> Paul Davis >> >
Re: Updating the CouchDB roadmap
Link might be handy: http://forrest.apache.org/forrest-issues.html On Fri, Dec 18, 2009 at 12:09 PM, Paul Davis wrote: > On Fri, Dec 18, 2009 at 12:05 PM, Noah Slater wrote: >> Hey, >> >> Does JIRA have a page what we could use as the roadmap? >> >> That would have the added advantage of updating itself automatically as we >> edited tickets. >> >> I found the roadmap tab from the main CouchDB page, but it doesn't have any >> tickets for post 0.10 on it. >> >> Thoughts? >> >> Thanks, >> >> Noah > > There was that one page that listed tickets in a format that you said > you were going to include in the release procedure. That's about all I > can think of other than saving a query which isn't nearly as awesome. > > There's also an example from the Apache Forrest site [1] that lists > open issues for the next release on their site which might also be an > interesting approach. > > HTH, > Paul Davis > > Paul Davis >
Re: Updating the CouchDB roadmap
On Fri, Dec 18, 2009 at 12:05 PM, Noah Slater wrote: > Hey, > > Does JIRA have a page what we could use as the roadmap? > > That would have the added advantage of updating itself automatically as we > edited tickets. > > I found the roadmap tab from the main CouchDB page, but it doesn't have any > tickets for post 0.10 on it. > > Thoughts? > > Thanks, > > Noah There was that one page that listed tickets in a format that you said you were going to include in the release procedure. That's about all I can think of other than saving a query which isn't nearly as awesome. There's also an example from the Apache Forrest site [1] that lists open issues for the next release on their site which might also be an interesting approach. HTH, Paul Davis Paul Davis
Re: Updating the CouchDB roadmap
Hey, Does JIRA have a page what we could use as the roadmap? That would have the added advantage of updating itself automatically as we edited tickets. I found the roadmap tab from the main CouchDB page, but it doesn't have any tickets for post 0.10 on it. Thoughts? Thanks, Noah
Re: Updating the CouchDB roadmap
On 18 Dec 2009, at 16:45, Dirkjan Ochtman wrote: > That said, it's perfectly alright if there's no roadmap at all, I'm > just surprised by the lack of thoughts from the core developers (who > are usually the ones to have these ideas) in this thread. Three of the core developers have been busy attending to real life for the last few weeks. :)
Re: Updating the CouchDB roadmap
On Fri, Dec 18, 2009 at 17:02, Paul Davis wrote: > I'm not really a fan of roadmaps. We get new features when people > write them. Everyone has the ability to write code, submit it and get > a new feature. I can't tell you what feature you're going to write, so > why would I tell everyone else that I expect you to write a given > feature? Well, there are usually ideas floating around about things that should be done at some point, and I think it's helpful if there is at least an attempt at keeping a list of these things, so that people might look at them and infer things about the current state of the software, or may start to help out because it's something they want themselves. That said, it's perfectly alright if there's no roadmap at all, I'm just surprised by the lack of thoughts from the core developers (who are usually the ones to have these ideas) in this thread. Cheers, Dirkjan
Re: Updating the CouchDB roadmap
On Fri, Dec 18, 2009 at 2:39 AM, Dirkjan Ochtman wrote: > It seems weird that none of the core developers have bothered to write > up some of their ideas here, for ten days running now. I understand > you're all busy with Relaxed, but it doesn't have to take so long, > does it? IMO it would be nice to have some kind of idea of where > CouchDB is going and/or what will be in the next release. > > Cheers, > > Dirkjan > I'm not really a fan of roadmaps. We get new features when people write them. Everyone has the ability to write code, submit it and get a new feature. I can't tell you what feature you're going to write, so why would I tell everyone else that I expect you to write a given feature? Granted, I would be perfectly happy referring to versions by sha1 so maybe I'm a bit crazy. HTH, Paul Davis
Re: Updating the CouchDB roadmap
I sort of agree with you, but in all fairness some of the core programmers have weighed in. To repeat my earlier post, I think it's a good time to put some stakes in the ground with respect to direction. I'm sure there are a number of parties interested in extending and making use of the internals and a lot has been discussed in terms of what could be done. A roadmap would be nice, especially since there is growing corporate support, a key selling point for CouchDB. On Dec 18, 2009, at 2:39 AM, Dirkjan Ochtman wrote: > It seems weird that none of the core developers have bothered to write > up some of their ideas here, for ten days running now. I understand > you're all busy with Relaxed, but it doesn't have to take so long, > does it? IMO it would be nice to have some kind of idea of where > CouchDB is going and/or what will be in the next release. > > Cheers, > > Dirkjan
Re: Updating the CouchDB roadmap
It seems weird that none of the core developers have bothered to write up some of their ideas here, for ten days running now. I understand you're all busy with Relaxed, but it doesn't have to take so long, does it? IMO it would be nice to have some kind of idea of where CouchDB is going and/or what will be in the next release. Cheers, Dirkjan
Re: Updating the CouchDB roadmap
On Tue, Dec 15, 2009 at 11:13 AM, Benoit Chesneau wrote: > On Thu, Dec 3, 2009 at 8:29 PM, Noah Slater wrote: >> Hey, >> >> As part of the release procedure, this is a request to update the roadmap >> document: >> >> http://couchdb.apache.org/roadmap.html >> >> Please comment on what should be added, and what should be removed. >> > > for next release I would like to have : > - authorization per database > - a global notification handler which would allow an indexer (or > anything else) to listen changes without opening a connection per db. > Also maybe we should define a global way to index document content and > send it on an indexer like we do for view server ? > - Better RFC 2616 compliance: davisp and me started to write on > webmachine couchdb > > Other stuff but I don't think it's possible for next release : > > native couchdb clustering : possibility to dispatch database and docs > across multiple nodes that could be added on the fly. > > > I think that's thse features could be removed from the roadmap : > > Continuous replication > Pure tail-append storage > Update API to parse client requests in JavaScript > Cookie authentication support > Windows build supports > > > - benoit > "Windows build support" should probably be "make windows dance to the posix tune" or alternatively "Windows support for DB compaction and deletion."
Re: Updating the CouchDB roadmap
On Thu, Dec 3, 2009 at 8:29 PM, Noah Slater wrote: > Hey, > > As part of the release procedure, this is a request to update the roadmap > document: > > http://couchdb.apache.org/roadmap.html > > Please comment on what should be added, and what should be removed. > for next release I would like to have : - authorization per database - a global notification handler which would allow an indexer (or anything else) to listen changes without opening a connection per db. Also maybe we should define a global way to index document content and send it on an indexer like we do for view server ? - Better RFC 2616 compliance: davisp and me started to write on webmachine couchdb Other stuff but I don't think it's possible for next release : native couchdb clustering : possibility to dispatch database and docs across multiple nodes that could be added on the fly. I think that's thse features could be removed from the roadmap : Continuous replication Pure tail-append storage Update API to parse client requests in JavaScript Cookie authentication support Windows build supports - benoit
Re: Updating the CouchDB roadmap
On 8 Dec 2009, at 02:48, ko...@fillibach.de wrote: > Quoting Noah Slater : >> As part of the release procedure, this is a request to update the roadmap >> document: >> Please comment on what should be added, and what should be removed. > > What I would like to see is "map/reduce chaining", as this really would blow > away most limitations currently imposed by couchdb. A good example for this > would be "get the 10 most popular items from a tag cloud". > > Of course, this also might affect efficiency, as every layer of map/reducing > imposes housekeeping and update costs. I haven't seen a solution yet that "works" on anything but small databases. If somebody comes up with a generic, fast, solution, I'd be all for it, but until then I'd not want to add it to CouchDB. Cheers Jan --
Re: Updating the CouchDB roadmap
that's ticket 583 - https://issues.apache.org/jira/browse/COUCHDB-583 The ticket's title is no longer fair. One of the last comments mentions the possibility of storing attachments in gzip compressed form (suggestion from Damien). I submitted a patch for that feature yesterday. cheers On Fri, Dec 4, 2009 at 7:17 PM, Robert Newson wrote: > Support for compressed attachments? I think there's a ticket for it, > but the basic idea is to support Accept-Encoding/Content-Encoding form > the client and store the attachment with compression (and > decompressing on demand). > > A bulk insertion endpoint that included attachments (without base64 > inflation) would also be nice. > > On Fri, Dec 4, 2009 at 5:55 PM, Dirkjan Ochtman wrote: >> On Fri, Dec 4, 2009 at 18:32, Noah Slater wrote: >>> Hey, does anyone want to start the discussion off? >> >> Question from one of those trailing around on actual releases, that >> may help getting started: what big-ticket features are in trunk, but >> not 0.10.1? >> >> Cheers, >> >> Dirkjan >> > -- Filipe David Manana, fdman...@gmail.com PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
Re: Updating the CouchDB roadmap
I'd like to see something like the jira-486: some refactoring of the internals, better separation of concerns, etc.. the idea being to enable hackers who wish to extend the capabilities of the internals in a somewhat principled way. I think the code base is at the size (~15K lines in src/couchdb) now where it's still manageable but it's increasingly difficult to understand all the pieces in any depth given the functionality packed into it. I know there's been lots of discussion around this on irc, etc.. it strikes me that the time is right to put a stake in the ground on it. Cheer, Bob On Dec 3, 2009, at 2:29 PM, Noah Slater wrote: > Hey, > > As part of the release procedure, this is a request to update the roadmap > document: > > http://couchdb.apache.org/roadmap.html > > Please comment on what should be added, and what should be removed. > > After a we reach consensus, I will update the roadmap. > > Thanks, > > Noah
Re: Updating the CouchDB roadmap
Quoting Noah Slater : As part of the release procedure, this is a request to update the roadmap document: Please comment on what should be added, and what should be removed. What I would like to see is "map/reduce chaining", as this really would blow away most limitations currently imposed by couchdb. A good example for this would be "get the 10 most popular items from a tag cloud". Of course, this also might affect efficiency, as every layer of map/reducing imposes housekeeping and update costs. Cheers, Kosta
Re: Updating the CouchDB roadmap
Support for compressed attachments? I think there's a ticket for it, but the basic idea is to support Accept-Encoding/Content-Encoding form the client and store the attachment with compression (and decompressing on demand). A bulk insertion endpoint that included attachments (without base64 inflation) would also be nice. On Fri, Dec 4, 2009 at 5:55 PM, Dirkjan Ochtman wrote: > On Fri, Dec 4, 2009 at 18:32, Noah Slater wrote: >> Hey, does anyone want to start the discussion off? > > Question from one of those trailing around on actual releases, that > may help getting started: what big-ticket features are in trunk, but > not 0.10.1? > > Cheers, > > Dirkjan >
Re: Updating the CouchDB roadmap
On Fri, Dec 4, 2009 at 18:32, Noah Slater wrote: > Hey, does anyone want to start the discussion off? Question from one of those trailing around on actual releases, that may help getting started: what big-ticket features are in trunk, but not 0.10.1? Cheers, Dirkjan
Re: Updating the CouchDB roadmap
On 3 Dec 2009, at 19:29, Noah Slater wrote: > As part of the release procedure, this is a request to update the roadmap > document: > > http://couchdb.apache.org/roadmap.html > > Please comment on what should be added, and what should be removed. > > After a we reach consensus, I will update the roadmap. Hey, does anyone want to start the discussion off?
Updating the CouchDB roadmap
Hey, As part of the release procedure, this is a request to update the roadmap document: http://couchdb.apache.org/roadmap.html Please comment on what should be added, and what should be removed. After a we reach consensus, I will update the roadmap. Thanks, Noah
