As a novice, outside user and someone who hasn't followed the CouchDB history from the beggining, I always imagined that the idea of having complete apps running on top of CouchDB was something that emerged directly and straightforwardly from the everything-is-HTTP paradigm. It feels right to let people use the REST infrastructure that is already working to output other things instead of just default JSON, and you already have a nice solution: the limited-access Javascript engine. Again, I think that when you developed this, you were just following the logic: what is the next step after having a HTTP-only document database?
The CouchApp branch merges with the replication branch in the concept of entire apps being cloned (enabling personal webapps for all things) with one _replicate command. The bigger problem, as I see, besides the naming, which is really confusing, is the work it takes to create a simple index for non-CouchApps. If you're writing a CouchApp then you're good with the CLI tools, the directory structure, the handwritten indexes and so on, but if you're writing a regular 3-tier application, having to work with directories and third-party tools is not great. Also, I agree with everything Paul Okstad is saying. On Wed, May 6, 2015 at 2:44 PM, Jan Lehnardt <[email protected]> wrote: > > > On 06 May 2015, at 19:39, Giovanni Lenzi <[email protected]> wrote: > > > > 2015-05-06 19:20 GMT+02:00 Jan Lehnardt <[email protected]>: > > > >> > >>> On 06 May 2015, at 18:59, Giovanni Lenzi <[email protected]> > wrote: > >>> > >>>> To get this rolling, we need to understand what we do and why we do > it. > >>> > >>> Considered couchapps new amazing features( > >>> http://markmail.org/message/poxvkumqqi4fugeo and > >>> http://markmail.org/message/rfbczt46ytlldjtj) and ermouth proposal > for a > >>> platform-indipendent and browser-only couchapp development environment( > >>> http://markmail.org/message/rckxmbx3tl7nags5), Couchapps can really > have > >>> big impact on CouchDB adoption-rate... so I think they are a big plus > for > >>> the project. > >> > >> That is fantastic! Again, I’m not advocating to remove any of the tech > >> that makes this happen. > >> > >>> Furthermore, as CouchDB Hosting provider, I can say Couchapps are > >>> extensively used by users..so the story could be instead to give them > >>> more visibility, by advocating them and clarifying what they can and > >> cannot > >>> do.. with facts, tutorials, examples and benchmarks. > >> > >> These are action items. Not a story. Let’s work on the story on > marketing@ > >> , > >> before we agree on action items. > >> > >> > > The story could be: "CouchDB, the only web, app and db server cake" , > where > > the user can choose to eat only one slice of the cake or eat it all.. :)) > > > > This includes all CouchDB features, withouth sacrificing netiher > couchapps, > > neither core functionalities > > > > Be sure to bring this up on marketing@! :) > > Best > Jan > -- > > > > > > >> Best > >> Jan > >> -- > >> “It is difficult to get a man to understand something, > >> when his salary depends upon his not understanding it.” > >> — Upton Sinclair > >> > >> > >> > >> > >>> > >>> > >>> > >>> 2015-05-06 18:24 GMT+02:00 Jan Lehnardt <[email protected]>: > >>> > >>>> > >>>>> On 06 May 2015, at 18:18, Alexander Shorin <[email protected]> wrote: > >>>>> > >>>>> On Wed, May 6, 2015 at 6:49 PM, Giovanni Lenzi < > [email protected]> > >>>> wrote: > >>>>>> What you all think about it? > >>>>> > >>>>> I think we need just clarify what CouchApp is, define it's show cases > >>>>> and area where they are works perfectly. > >>>>> First step is to back couchapp.org online (almost done). Then, just > >>>>> fill it the right content. That will solve any confusions. > >>>> > >>>> Before we fix anything, we need to understand how to fix it. To > >> understand > >>>> how to fix it we need to understand what we do. To understand what we > >> do, > >>>> we need to understand why we do it. — Hence, we first need to find a > >> “The > >>>> Why of CouchDB” story that reflects our intentions before any of the > >> other > >>>> decisions can happen. That’s what my original message is about. > >>>> > >>>> > >>>>> I'm -1 for removal CouchApps as a since it's not possible as > CouchApps > >>>>> are not a some entity, but a way of organizing design documents in > >>>>> order to solve some specific problem. > >>>> > >>>> The problem is, as outlined in my emails on marketing@ that I linked > >>>> earlier > >>>> that “CouchApp” means at least eight different things to different > >> groups > >>>> of > >>>> people. That is terribly confusing and makes people new to CouchDB > >> leave us > >>>> in spades because it is just too complicated. > >>>> > >>>> I never meant for the actual technical features in CouchDB to be > removed > >>>> and > >>>> I never said so. > >>>> > >>>>> We just need to find a sweet spot, a right vector for their future > >> since > >>>> as > >>>>> for now I feel CouchApp as a technology is just lost in space. > >>>> > >>>> Exactly, and its harming CouchDB. > >>>> > >>>> To get this rolling, we need to understand what we do and why we do > it. > >>>> Then > >>>> we can decide if and how “CouchApp” in whatever form fits into this. > >>>> > >>>> Best > >>>> Jan > >>>> -- > > -- > Professional Support for Apache CouchDB: > http://www.neighbourhood.ie/couchdb-support/ > >
