On 15.04.2008, at 17:05, Damien Katz wrote:
Storage compaction and mochiweb are now checked in. We need to think
about getting the next release done.
What should the criteria be for the next release? Here are some of
my thoughts:
If we plan any significant interface changes in HTTP, javascript,
etc, they should be done by 0.8.0. The longer we wait to make
interface changes, the more apps and libraries we break and the less
likely it will ever get done.
In the backwards-incompatible changes department, here's what I think
would be nice to get into 0.8:
* RESTful attachments API: Use DELETE/PUT for attachment manipulation;
maybe provide a multipart interface for uploads, and for retrieving
the JSON doc with all attachments (in addition too--or even instead
of--the current inlining into the JSON)
* Decide on the JSON API to use and stick with it; switching libs will
break DB files. It'd probably be best to use mochijson.erl or
mochison2.erl, as those come with MochiWeb and are included in our
codebase anyway, and we'd get rid of the patched up cjson.erl, making
updating from upstream easier.
* Not sure, but implementing reduce/combine functionality will
probably cause a change to the database form, right? If we agree to
"wait" about a month for the release, is reduce realistically
implementable for 0.8? ;)
We need to have an upgrade utility and instructions for going from
0.7 to 0.8
Right, very important.
I've added rudimentary dump/load scripts to my couchdb-python library,
available here:
<http://code.google.com/p/couchdb-python/source/browse/trunk/couchdb/tools/
>
* dump.py takes a database URL and writes all the documents it
contains to stdout using a MIME multipart format.
* load.py takes the URL of an empty target database, and reads
documents from stdin, using the same multipart format.
Those don't support attachments yet, and the process should probably
use the same HTTP API used by replication (think "offline
replication"). In any case, the multipart format works pretty well,
and I suggest we adopt it when we add a built-in dump/load interface.
You can nest multipart envelopes (for attachments), and there's no
need to load the complete file into memory and parse it into a JSON
object tree (and vice versa).
Bugs and client compatibility problems with mochiweb are okay for
0.8.0 As problems crop up, we'll fix them and release patches.
I think we should get the test suite to reliably succeed under Safari,
which is the only current problem I'm aware of. If the suite fails
(intermittently even) on a fresh official release, that's not such a
good first impression.
The database internals should not have known bugs, but this is still
alpha software. I think we need to make it clearer on the site,
download pages, readme, etc that CouchDB isn't reliable yet. For
example, CouchDB isn't an acid database on OSX (maybe all BSDs), but
is on Linux, because of platform specific flags etc. These are
problems that will be fixed before shipping, but for now might cause
a lot of pain.
Yeah, the alpha status needs to be made more obvious. On a somewhat
related note, some of the docs also need to be reviewed and changed so
that it's clearer which features work right now, and which features
are incomplete or only planned for the future (search, reduce/combine,
authn/authz/validation, etc).
As Jan mentioned (and I said on IRC), I'll be on vacation and mostly
offline for the next 3 weeks. I've been lucky to get a lot of code
into CouchDB in the last couple of weeks (SpiderMonkey, MochiWeb, many
Futon enhancements), so I'd also really like to be involved when we
package things up and subsequently need to support the release by
answering questions, helping to troubleshoot problems, and fixing bugs
(and throwing the virtual release party ;) ). And of course there's
still a number of formal things that need to be sorted out before we
can make our first release out of the Incubator. So I'd be in favor of
targetting a 0.8 release in mid May.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
