Jan Lehnardt wrote:
Re. a couple of things below:
This should be definitely something @users should be involved in.. at least
those interested in Couchapps.
To recap:
Jan: wants to remove Couchapp name and design doc functions because it
finds them to be source of confusion
This does not adequately reflects my position. I don’t suggest to remove
any of the things that make CouchApps possible.
My larger argument can be foundhttp://markmail.org/message/no3jfksdxjcgxz4d
andhttp://markmail.org/message/xla3hulea4lo5duw
tl;dr: I’d like us to think about how the CouchApp (or whatever the
final name might be) story fits into the larger CouchDB story of “Data where
you need it.” — Not necessarily how the slogan made be “true” in the context
of CouchApps (e.g. “Data (and logic) where you need it.”, but more:
- CouchDB’s core feature is geographically distributed replication.
Really? That's the argument that lead to CouchBase.
I’m a Couchbase co-founder and I can assure you you are mistaken.
Maybe I'm confused then. Seems to me that CouchBase is a memcached
front-end, with CouchDB style replication on the backend. Serves one
set of purposes, but very different from the initial way CouchDB is
presented (back to "CouchDB, the Definitive Guide"). But maybe that's
why you're now doing CouchBase, and not CouchDB or Cloudant.
Yes, MVCC w/ replication is A core feature, but, at least to me, Couch's core
feature is a full-featured HTTP interface -- everything is a resource, accessed
through RESTful HTTP operations.
What is the one thing that make CouchDB unique? REST or Replication?
Why does it have to be one or the other. To me, it's the combined set
of features. (Parenthetically, MVCC w/ replication is not unique to
CouchDB - kind of goes back to Lotus Notes, which I believe inspired
CouchDB :-)
To wit, this isn’t about removing everything that isn’t replication. REST will
stay around, we may have other interfaces too at some point, but not anytime
soon. Either way, REST is not what makes CouchDB unique.
I understand it is an important feature to you, much like many other features
are very important to other people. But overall, CouchDB’s unique feature is
replication.
Well... that's YOUR opinion; granted an important one - but you might
want to get a better sense of what the broader user base thinks.
I’ve spent most of my time since 2007 advocating CouchDB to thousands of people
in person and even more online. CouchDB’s “AppServer” features are neither
straightforward nor does the term fit nicely. People are confused by the fact
that there are three different “couchapp” tools in various languages, that you
need one of them to manage design docs, just to query CouchDB (I’m sure glad we
have mango now, where the steps are “create index, start querying”, like in
every other database). There is confusion of using “couchapp” to manage views,
when CouchApps mean so much more than just managing map/reduce functions. I can
go on for hours how this is confusing for first-time experiences that people
have told me and keep telling me.
What seems confusing is that the tooling is conflated with the AppServer
features.
To use a perhaps poor analogy - Jetty is a Java App Server. There are
lots of Java IDEs that can be used to generate Java Apps. Somehow,
people don't get confused about what Jetty does, just because there are
multiple tool sets.
Personally, what I find confusing is why anyone used Python tooling to
generate JavaScript webapps, to be loaded into an Erlang-based server.
The logic behind erica, I kind of understand.
Rather than retire the term, or relegate it to obsucrity - market it aggressively! Perhaps to
the the extent of changing the current tag line on couchdb.apache.org from "A Database
for the Web" to "A Database and Integrated App Server for the Web.”
I’ll refer you to the “The Why of CouchDB” discussion in the marketing@
archives.
Can you provide a pointer? I can't seem to find searchable archive of
marketing@. Thanks!
Miles
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
