> Neat idea. I've been working (off and on) on a number of Couchapps that might > be a great fit. They're simple "Python couchapp" bundles rather than Kanso, > especially since many of them were started a while ago:
There is a traditional-couchapp package for kanso that should work for your apps. > All of these are designed to run in a shared database setting (e.g. I could > theoretically store all my photos and geodata and text notes in a single > database) and so might be a great fit for Garden20 [why twenty?] assuming > your app approval process is sympathetic to beta (and in some cases, > pre-alpha) software ;-) With this release each app installs into its own db in couch. It was too much cognitive overhead for users to decide where to install it. I think in the future apps can have runtime app dependencies specified, and say if they want to be installed into an existing db. > > Garden20 [why twenty?] Just wanted a short, easy to remember url. Also the site itself is a garden, so its just one of many. One could make a garden21 and host completely different apps there. Also it's a play on 2.0 but that's a bit lame so pretend I did not say that. > Glad you're keeping the CouchApp dream alive. I've got a dream to someday > figure out a sort of couchOS server platform where, say, gently sandboxed > node.js apps can track a whole family/small office's data in CouchDB, with a > bit of OAuth, BrowserID and Web Intents thrown in for good measure. Apps like > ShutterStem and some media center stuff lower down on my list could benefit > from being able to run OS-level processes outside of _view/_show/_list — but > I think simply having Garden to make the basic CouchApp stuff more > approachable to more people is a great step forward. > Yes, I also want to have a little more horsepower on the installed gardens. I think the next release would focus on this. There are lots of options, but wanted to discuss with the community to get the best way forward.
