> I would also only want the browser interface. I don't even want the user to > know anything resides locally. Of course they will have to check some > approval box at some point, but users never understand those anyway. >
I agree. Users are very easily confused. A download and run local option would be way over the top for a large portion of people. But giving them at least the choice? Is that not at least empowering them with the option to own their data? >> To me, making this a nice experience that comes for free with a modern >> browser is more compelling, but for those who want to run an Apache >> CouchDB on their own desktop some combination of system-tray and >> chromecouch work could be cool. >> I had stumbled across pouchdb. It looks very cool and promising. Do you see it being able to be the same as couch? One issue I see is when developing a couchapp in that way is then having to think about all the different 'containers' it will be in. Coming from a java background, this was always a headache (MIDP profiles, web application containers). I know in the past I asked the couchdb mailing list about linking local js files into the view server. One side of the no answer was that it would make couch apps not portable. Now I can see the benefit of that. I guess similar issues with even the desktop couchapp is what supporting stuff is installed...geocouch, couch-lucerne, elastic search. To get desktop couch as a browser plugin seems like work...3-4 main browsers * 3 main os's. Has anyone tried? So I think it comes down to some main questions: 1. Are local-remote couchapps end user friendly? 2. How do we handle what couch features are available? 3. whats the best way to implement....browser plugin, webstart like app, end user standalone install. -- Twitter: @eckoit http://eckoit.com - Keep what you hear. http://opendoorstories.com - Create Experiences
