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 AF0DB99F4 for ; Sun, 10 Jun 2012 18:05:14 +0000 (UTC) Received: (qmail 66237 invoked by uid 500); 10 Jun 2012 18:05:14 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 66203 invoked by uid 500); 10 Jun 2012 18:05:14 -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 66191 invoked by uid 99); 10 Jun 2012 18:05:14 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Jun 2012 18:05:14 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Jun 2012 18:05:06 +0000 Received: from [172.20.10.2] (unknown [176.4.38.58]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id D5C4314256 for ; Sun, 10 Jun 2012 20:06:48 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1278) Subject: Re: So, how do we get the Mac binary on the home page? From: Jan Lehnardt In-Reply-To: Date: Sun, 10 Jun 2012 19:58:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1C4B6690-4F1A-4243-8CCA-31F06378BCE7@cloudno.de> <055960F2-4691-4478-B6DC-4A4D4B2CCEC8@gmail.com> <81F2C009-E972-4A88-9829-DB249048B1AF@cloudno.de> <1F39284F-0021-46F3-80BC-1F0293D72AD3@apache.org> <642F3A88-2B4F-4690-836E-D87105A1A500@cloudno.de> <639AC10D-4369-44F0-972A-032807FB5946@cloudno.de> <0C9AFF49-C71F-453E-AE90-0A1232F1ECB1@cloudno.de> <11E433BC-B7C9-434A-8B25-6DD42832EEC8@cloudno.de> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1278) On Jun 9, 2012, at 12:22 , Benoit Chesneau wrote: > On Sat, Jun 9, 2012 at 11:40 AM, Hans J Schroeder = wrote: >> Hi Dave, >>=20 >>> #1 and #2 make sense, but might not be immediately obvious. They = could >>> wait, its more >>> about documenting somewhere. >>=20 >> It is exactly where to put them. What would be your choice? >> I also disagree about documentation needs for this. Apple users don't = want and don't need to know such details. It just works. :) >=20 >> The exact locations are also visible from the configuration page. = Every CouchDB user is familiar with this. >>=20 >=20 > Paths to find dqtq and ibi should be documented somewhere though. So > someone that want to delete the application can delete the data. > (data shouldn't be in the application resources) . >=20 >>> If its not hard to fix #3 and #4 we should do that first. This means >>> CouchDB.app could >>> run read-only in /Applications, which it doesn't atm. >>=20 >> That would be nice and falls in the sandboxing category which we = definitely should adopt. >> But I see no immediate need for this for the current version. >=20 > Since 1st june, OSX qpps qre required to be sandboxed. This is true only for apps published through the AppStore. While it would be desirable to be part of this, I think we can publish the current version(s) as is on the website and then work on an AppStore compatible one. > Which is ino > better for the end user. We should really adapt the current version to > have it. Tjis isn't a show stopper, but still something usefull qnd > not so hard to implement. >>=20 >> Changing is also not that easy because there are dependencies: >> The log is connected to the logfile viewer. >> The uri is connected to the shutdown scripts to do a final commit. >=20 > Well such things are already working in rcouchx. I will have a look in > the code of these new version for that. >=20 >>=20 >> Would you stop publishing without these changes. >>=20 >>=20 >=20 > Is this a question ? :) >=20 >=20 > Anyway for the port part I still think it`s important. I think we > could have a default to 5984 and if it`s used, use another port > automatically and notify it. Good call on the user-friendlyness here. I think binding to 5984 by default is the right thing (because our docs currently all mention that), but if 5984 is taken, we can bind to another one and send a notification via the UI. But again, I think this isn't blocking the release of the current binaries. Cheers Jan --=20 PS: Your q&a keys seem at odds :)