> 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.