incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: So, how do we get the Mac binary on the home page?
Date Sun, 10 Jun 2012 17:58:09 GMT

On Jun 9, 2012, at 12:22 , Benoit Chesneau wrote:

> On Sat, Jun 9, 2012 at 11:40 AM, Hans J Schroeder <hs@cloudno.de> wrote:
>> Hi Dave,
>> 
>>> #1 and #2 make sense, but might not be immediately obvious. They could
>>> wait, its more
>>> about documenting somewhere.
>> 
>> 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. :)
> 
>> The exact locations are also visible from the configuration page. Every CouchDB user
is familiar with this.
>> 
> 
> 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) .
> 
>>> 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.
>> 
>> 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.
> 
> 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.


>> 
>> 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.
> 
> Well such things are already working in rcouchx. I will have a look in
> the code of these new version for that.
> 
>> 
>> Would you stop publishing without these changes.
>> 
>> 
> 
> Is this a question ? :)
> 
> 
> 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
-- 
PS: Your q&a keys seem at odds :)


Mime
View raw message