> On 06 May 2015, at 18:54, Miles Fidelman <[email protected]> wrote: > > Jan Lehnardt wrote: >>> On 06 May 2015, at 17:57, Giovanni Lenzi<[email protected]> wrote: >>> >>> Given the importance of the topic: the future of couchapp... I'm moving >>> this from the @marketing to the user@ mailing list. >> I’d say this is too early, would prefer we keep this on marketing@ until >> we have the messaging right. Everything else follows from them. Given that >> user@ is missing the entire “the why of CouchDB” context that marketing@ >> has, I’d say moving this is premature. >> >> I also *could* see this as a cheap ploy to quickly garner public pressure >> against my position, but in good faith, I won’t assume this is your motive. > > If this is the kind of discussion going on, on the marketing list, then you > REALLY need to open it up to user feedback. I think you're going off track.
Noted. > > 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. > > 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? 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. > >> >> - We also have somewhat quirky, while technically neat, applications that can >> live inside CouchDB. >> >> I don’t think that last bit helps paint the big picture CouchDB story at all. >> Granted, I’m making a deliberately weak attempt of tying things together >> (because I don’t know any better), but this is to get you thinking about how >> this could fit in our larger narrative, if at all. > > From this user's perspective, you're 100% wrong on this. In your opinion. > The fact that you can use CouchDB as an App Server is of particularly high > value; the more so that the Apps can run in a browser. More to the point - > it's an HTML5 WebApp server, making it a full platform for RESTful > applications. This is a great approach to get this into the core narrative of CouchDB, would love for you to join the discussion on marketing@. > >> My current thinking is that we can’t make it clear and thus should figure >> out a >> plan to retire “CouchApp”, while still allowing all the cool tech, and find a >> new name for the concept that can live on without making CouchDB’s core >> message >> unclear. >> > > Hell no! Hell yes, let’s keep CouchDB a confusing mess. > Maybe the tooling for CouchApps is a bit funky, but the support for them is > (IMHO) core features of Couch. And the notion of Couch as an App Server is > pretty straightforward - and the term fits quite nicely. 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. > > 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. Best Jan -- > >> Please join us on the [email protected] list for this discussion. > > Done :-) > > Miles Fidleman > > > -- > 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/
