Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1AB9690DF for ; Sun, 6 Nov 2011 15:41:45 +0000 (UTC) Received: (qmail 53184 invoked by uid 500); 6 Nov 2011 15:41:44 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 53154 invoked by uid 500); 6 Nov 2011 15:41:44 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 53146 invoked by uid 99); 6 Nov 2011 15:41:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2011 15:41:44 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of nslater@tumbolia.org designates 209.85.214.52 as permitted sender) Received: from [209.85.214.52] (HELO mail-bw0-f52.google.com) (209.85.214.52) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Nov 2011 15:41:39 +0000 Received: by bkbc12 with SMTP id c12so4819925bkb.11 for ; Sun, 06 Nov 2011 07:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tumbolia.org; s=google; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=8W1ZLUdqy9DcmHnb+0OEM9rNAhLs3PK3/ckqYNT/6YA=; b=SYIMKULAyBhJ3IyB1TWYkg8V66Z3DLlJptIC/0jtH7WWcOiB/dl2xtQqiupi7T8si9 l5Pa1LFcA+pS35jG/4k5f09aLuJphKV4lLu9slnxHGMN/0QEmIPWP1hTYjYO5/G3vidg KfX6uF6jCHcMfWU5VfMTHFhO2gEytuhJKJM9Y= MIME-Version: 1.0 Received: by 10.204.157.27 with SMTP id z27mr17058007bkw.8.1320594077830; Sun, 06 Nov 2011 07:41:17 -0800 (PST) Received: by 10.204.42.139 with HTTP; Sun, 6 Nov 2011 07:41:17 -0800 (PST) X-Originating-IP: [87.198.113.211] In-Reply-To: References: <785FABDB-2EF0-409A-A6C5-E9C8D498241B@apache.org> Date: Sun, 6 Nov 2011 15:41:17 +0000 Message-ID: Subject: Re: Binary Downloads From: Noah Slater To: dev@couchdb.apache.org Content-Type: multipart/alternative; boundary=0015175d0a02e6d0f804b112c454 --0015175d0a02e6d0f804b112c454 Content-Type: text/plain; charset=ISO-8859-1 On Sun, Nov 6, 2011 at 2:13 PM, Riyad Kalla wrote: Many of you are too close to the problem to see it, but the 10-second > impression when you step into the Couch world (as compared to Mongo, Redis, > Orient, Raven or even Cassandra) is "... where do I download and run this > thing?" > I did a quick survey of the apps you mention, to see how they do it. http://www.mongodb.org/downloads Mongo offer a selection of packages for a bunch of popular architectures. When you download this package, it expands into a collection of pre-compiled executables and a README. You are able to run the MongoDB sever immediately. On the flip side, there is nothing to help you with operating system integration. No logging, no startup scripts, no data dirs, no man pages. http://redis.io/download Great download page, I love it. It looks about as complex as CouchDB, knowing what I know about CouchDB. For our new users, this wouldn't be the case. We should work on that. If our download page was more like this, that would be awesome. That's more of a design issue though. Note that this page works because it's well documented and clear. That's the only difference. http://code.google.com/p/orient/wiki/Download Really? Their downloads page is on a wiki, and it has XML fragments on it designed to work with Maven. That's about as failsome as you can get. The only thing that would make it worse would be if it had unrelated animated "DOWNLOAD NOW" ads on it. I downloaded a copy, read the readme.txt (which has a page of ASCII art to scroll past) and stopped when I saw that I had to run ant. You seriously thing this process is better than CouchDB's? Maybe you included this to make sure I was paying attention. ;) http://ravendb.net/download No mention of versions. As far as I can tell, there ARE no version. I was directed to some build server, with a list of recent builds. Quite confusing. So I downloaded one of them, and unpacked a directory full of files and directories. A readme.txt indicates that if I were running Windows, I could execute a binary to start a service or something. What is this I don't even. http://cassandra.apache.org/download/ Now this is much more interesting. Firstly, because they're an Apache project, so they should theoretically be bound by the same constraints that we are. Also, secondly, because they use an interpreted language. Unfortunately, however, for CouchDB to run, you need to, at a minimum, compile couchjs, which is a C programme. Which means it's platform dependant. That would stop us from providing -bin and -src packages. But we could, conceivably, distribute -bin packages for a bunch of common architectures. In these packages, the erl files would be pre-compiled, and the couchjs command would be pre-compiled. And you could run CouchDB from the source directory like we do currently when we're working on the source. I don't know how we'd do that with Autotools though, as I've never looked in to it before. Perhaps it's possible, perhaps it's not. CouchDB needs pre-build binaries, ready to unzip and run exactly as Jan > enumerated in his first post. Why? How many regular users of CouchDB come to the website looking to download and run CouchDB? How does that compare to the number of users who "apt-get install couchdb" or "brew install couchdb" or whatever? Are those people coming to the website looking to install CouchDB into a server environment, or are they looking for a local standalone app like CouchDBX? Just to re-iterate my position. CouchDB is a server. That is its primary function. It's not a desktop app. I wouldn't expect to download it into my Applications directory, or launch it by double clicking on an icon. Sure, it would be nice if something like that were available so that developers have an easy target to run local development work against, but that is a secondary concern. And in any case, people don't download software from websites any more. If you're on Debian, you use the Debian package manager. If you're on Ubuntu, you use the Ubuntu one. If you're on OS X, these days, you use the App Store. These package management systems offer a greater level of system level integration and ease of use than we could ever hope to achieve. Our users shouldn't be installing from source, really. I mean, there's no harm in it, but it's not an ideal scenario. My preference would be that they install CouchDB using whatever is native to the host operating system they're using. Perhaps we can provide information to that effect on our downloads page, to make the process as easy as possible. To point them in the right direction. I do think that tools like CouchDBX are useful. Or maybe something like MAMP, to help people get a local development environment set up as easily as possible. Though, I will note, that "brew install couchdb" is a lot easier than the same process for MySQL. But this sort of app is a separate concern. It's a project in its own right. If a committer wants to step up and maintain something like this, in a way that builds along with the main release artefacts, then that's awesome. I'm not holding my breath though. If committed community members want to maintain Windows builds, or single-serving apps, that's fantastic. We can, and should, promote them from our website. If organisations like Couchbase or Couchone want to help, even better. Okay, I just downloaded a copy of MongoDB for OS X to see what all the fuss was about. (Ed. I wrote the top part of this email after this part, naturally.) Given the hype, I was expecting some kind of app I could double click on, like CouchDBX, that would start a local MongoDB server and take care of all the setup for me automagically. Instead, I find a directory of pre-compiled executable files, and a README. I went back to the downloads page, and I see that there is an accompanying quick-start guide. http://www.mongodb.org/display/DOCS/Quickstart+OS+X The first thing they do is recommend you use your package manager to install MongoDB. The second thing they do is talk you though setting up a data directory, and then show you how to execute the MongoDB executable. Where do logs go? Do I have to figure out my own system for piping output to log files? Do I have to set up my own log rotation scripts? What do I need to do to get MongoDB running automatically when I log in? Where is the MongoDB man page? I guess there isn't one. What should I do about users? Is there a standard setup that maximises security? How is this superior to CouchDB in any way? They've traded everything in exchange for being able to run MongoDB immediately. And note that by immediately, I mean, without having to run "./configure && make install" first. Clearly, the complexities involved in executing such an arcane command (despite it being clearly documented, and backed by 30 years of common practice) are just too much for the average user to cope with. Nope. Forget about logs, and startup processes, and documentation, and security. Too complex for your average user. System administration is hard, let's go shopping! I'm sorry for the hyperbole, but I just don't get it. This isn't what we should be funnelling our users into. This isn't the direction we should be going in. CouchDB is a database server. Database servers are complex to set up. MongoDB hasn't found a silver bullet to make this easier, they've abdicated the responsibility entirely. You're on your own. They provide you with an executable, and the rest is up to you. All of it. And that's how CouchDB started life, before it got a proper build system that takes care of it for you. It reminds me of that post Mark Pilgrim did about the influx of trendy new editors, and how they focus so much on being hip they tend to lack the basics that other more editors have had for decades. Like copy and paste support. Seriously. Maybe there's room for a CouchDB lite, or a CouchDB client, or some other type of click-and-run app, with a pretty little logo. I definitely agree with that. Some users don't want a server. They don't care about logs. They don't care about man pages, and they almost certainly don't care about security. They want a nice, self-contained, app to play around with. And that's fine. But a division needs to be drawn between the two. TL;DR There are four proposals: 1. Improve our downloads page, because at the moment it kinda sucks. 2. Make it easier for people to run CouchDB from the source. 3. Improve the down-stream packaging situation. 4. Promote a desktop app version of CouchDB that comes with batteries included. And my thoughts on the above: 1. Yes, yes, yes. 2. Maybe, but I'm not sure the trade-off and potential problems are worth it. 3. Absolutely, but we need to work with downstream teams, instead of duplicating their effort. 4. Sure, but I don't see this becoming an "official" download. --0015175d0a02e6d0f804b112c454--