On 18 Aug 2009, at 03:13, Paul Davis wrote:
My understanding is also that we want an official distribution to
include
couchdb-lounge style clustering. There's two ways to go about it:
1) put it
all into the source tree and disable and enable features on build
time
(--enable-cluster) or 2) have separate trees (e.g. a core and a
cluster add
on) that can be used to create two releases (packaging time):
couchdb-1.0.tar.gz and couchdb-with-cluster.tar.gz
Erlang should allow us the flexibility to make clustering a runtime
configuration. As you state, its can be thought of as a toolbox for
creating db environments. If people want to shed bits of the toolbox
to target a phone, then I think that's more of an end user concern.
Or does the PMC want to public couchdb-mobile.tar.gz?
- Do we want to ship whatever release (cluster or not or both) of
CouchDB
with a small ecosystem (Futon, CouchApp)?
Futon is already in "core", sub-projecting it would be merely done to
attract more Futon developers. Maybe that can be achieved in other
ways,
too.
I think making it easier for developers to start hacking on Futon
would be pretty awesome. Though I'd put it more in the realm of us
being creative instead of creating a full on sub project for it.
that might include confusion what it means to be a "full on sub
project".
IMHO that is just moving source files to couchdb/futon/trunk/... and
setting
up svn externals (guesswork) or symlinks for couchdb proper accordingly.
I think CouchApp should be a packaging-time part of CouchDB and
installed by
default. This would add Python as a build dependency. Maybe we can
make
./configure smart enough to not install CouchApp and give a warning
when the
necessary dependencies are not met. Maybe we just add to the final
`make
install` output "Now go and install CouchApp from ...".
It'd take a lot of convincing for me to be supportive of having
couchapp in an apache-couchdb tarball. Especially when `sudo
easy_install couchapp` is handy.
Imagine a CouchDB distribution where a user has everything "ready to go"
instead of having to figure out what bits and pieces are needed next.
There's a long way to go with documentation and notices in the right
places (like after make install), but e.g. package manager users don't
get to see these.
- Do we want to foster plugins, extensions and other infrastructure
software or do we want to rely on the non CouchDB open source world
to come
up with them?
I'd like to see a place like the Firefox extension development
center but
for CouchDB plugins hosted on http://couchdb.apache.org.
I think having a place for plugins would be great. Though I tend to
wonder what type of requirements there would be if we hosted plugins
at the ASF. Somehow I'd think that requiring a signed legal document
on file would stifle widespread growth of the community.
I agree. The actual code could be distributed from some other place,
I'm not suggesting right away that all this has to be under the ASF/CLA
umbrella. Although clear steps on how to "get in" should be
documented.
Cheers
Jan
--
