On Jun 9, 2012, at 12:22 , Benoit Chesneau wrote: > On Sat, Jun 9, 2012 at 11:40 AM, Hans J Schroeder <h...@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 :)
