> On 06 May 2015, at 21:38, Miles Fidelman <[email protected]> wrote: > > 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.
I left Couchbase in 2013 exactly *because* they were not going after I believe CouchDB’s core strength is. Whatever Couchbase is doing is not influencing my thinking. This is 100% with my Apache CouchDB hat on. > >>> 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 :-) Because we need to pick *one* thing that describes our why: https://www.youtube.com/watch?v=sioZd3AxmnE >> >> 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. Hm no, that’s the consensus of the 2012 core developer meeting in Boston and the subsequent discussions here on marketing@. I’m merely relaying it and trying to move reality to a position that reflects that opinion. >> 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. It’s a total mess, you are right :) > >>> 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! Albeit clumsy: http://couchdb.markmail.org/search/?q=marketing#query:marketing%20list%3Aorg.apache.couchdb.marketing+page:1+state:facets But then I only found this thread on dev@: http://mail-archives.apache.org/mod_mbox/couchdb-dev/201307.mbox/%3cCAPaJBx47r382Qj5LEwLNam_sRuomHRs=7o0btfcmtwmmg-l...@mail.gmail.com%3e It looks like we talked about the pre marketing@ existing, sorry about the confusion :) Best Jan -- > > Miles > > -- > In theory, there is no difference between theory and practice. > In practice, there is. .... Yogi Berra > -- Professional Support for Apache CouchDB: http://www.neighbourhood.ie/couchdb-support/
