To get back to the conceptual and storytelling side of this… I buy Alexander’s > On 06 May 2015, at 14:23, Alexander Shorin <kxe...@gmail.com> wrote: > > So what is CouchApp is? > Again, the answer is in the name. CouchApp. Couch, App. CouchDB > Application. With first word everything is clear I hope (: > Application is not only an UI, but also uniform and consistent logic > about solving some single and specific problem.
and to distinguish between ddoc and couchApp we could start with the assumption that a couchApp would most of the time involve more than one ddoc. The benefit of that would be to: Instead of relying totally on the internal structure of the ddoc to establish a pattern we could Point to several ddocs having specific functions and Establish a pattern of ddocs as a basic definition of a couchApp One of my early decisions was to use one ddoc to hold the _rewrite for an app and in the same place keep some config data. This way I could use it as a router and employ several databases with different access settings Views, lists etc always need to be defined in a ddoc with its data, but this can then be seen as a way of equipping the data with an UI (wo/ logic) As CouchDB is not able to process more then one request at a time, the logic will to a large extend end up in the client and that means that there is likely to be one ddoc serving up the framework of the app and holding script components, style sheets, making ajax calls for components that very well can reside in several databases. A one-database-per-user or one-database-per-role approach with common data and functionality maintained in separate databases is a pattern that can be very useful. I also think that one-database-per-component is a CouchDB concept that fits well with the ease of replication for deployment and maintenance, e.g. when maintaining data and ddocs in a staging site before deployment. The point that I try to make is that if we define the CouchApp as a **set of ddocs** with separate functions in the app we could establish a pattern for CouchApps that enables a database to be a component (data with UI) rather than keep on talking about CouchApp and ddoc as the same thing. A minimal pattern for me would be: One db/ddoc could hold the router (_rewrite) and some config data One db/ddoc could hold the client side of the app and the main logic together with some app-wide user prefs several others per-user, per-role or per-component databases could hold data with ddocs to provide views and markup Does anyone else have other patterns for a CouchApp that involves several ddocs with specialized roles in the app? Such patterns might help define CouchApp in a better way and keep it separate from the abstract ddoc. johs > On 06 May 2015, at 17:05, Jan Lehnardt <j...@apache.org> wrote: > > Good reminder, thanks Joan! > > I’d say as long as we are discussing the marketing angle, things > can be here, even when they concern technical things. > > Anything concrete of course will have to run on dev@. > > Best > Jan > -- > >> On 06 May 2015, at 16:36, Joan Touzet <woh...@apache.org> wrote: >> >> PMC hat on: >> >> I want to remind people that we appear to be having a feature >> and development discussion on marketing@. I recommend we separate out >> marketing related topics from development. Renaming ddocs could very >> well have larger ramifications for the source code base; this >> decision should not be made lightly and definitely should not be >> made on marketing@. >> >> -Joan >> >> ----- Original Message ----- >>> From: "Jan Lehnardt" <j...@apache.org> >>> To: marketing@couchdb.apache.org >>> Sent: Wednesday, May 6, 2015 9:28:54 AM >>> Subject: Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB >>> Articles, Pills and Tutorials Ideas) >>> >>> Heya, >>> >>> great discussion here, let’s keep it going! >>> >>> I love the idea of getting a few more people into a joint session to >>> discuss the future of CouchApps, as Johs suggested. >>> >>> The current thread is focussing on “how to fix CouchApps”, which we >>> should continue to figure out. >>> >>> I’d also like push towards thinking 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. >>> >>> - Replication becomes really powerful with projects like PouchDB and >>> TouchDB that take individual user data offline on their browsers and >>> phones. >>> >>> - The industry’s current battle is vendor-lock-in with proprietary >>> backend as a service solutions that may or may not have offline >>> capabilities. >>> >>> - CouchDB is the only serious Open Source contender in this. >>> >>> - 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. >>> >>> 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. >>> >>> But I am very open to finding a way to make it fit. This is where you >>> come in :) >>> >>> Best >>> Jan >>> -- >>> >>> >>> >>> >>> >>>> On 06 May 2015, at 14:23, Alexander Shorin <kxe...@gmail.com> >>>> wrote: >>>> >>>> On Wed, May 6, 2015 at 3:15 PM, Johs Ensby <j...@b2w.com> wrote: >>>>>> On 06 May 2015, at 13:55, Giovanni Lenzi <g.le...@smileupps.com> >>>>>> wrote: >>>>>> >>>>>> They could also be: >>>>>> - design doc app >>>>>> - design app >>>>>> - couchdb apps >>>>>> - couchdb based apps >>>>>> >>>>>> But they all seem very complicated to me. What do you think? >>>>> >>>>> I would prefer to think of the “app” as a combination of things >>>>> that use ddoc to link functionality to the data, or provide an >>>>> API of the data for the "app". >>>> >>>> I think we need to set the terminology right. >>>> >>>> What is design document? >>>> A special document which _id starts with _design/ prefix which >>>> contains design functions. >>>> >>>> What are design functions? >>>> A programming code that stored in design document and executed on >>>> CouchDB side. >>>> >>>> Which design functions are could be? >>>> Show, list, update, validate_doc_update, map, reduce. >>>> >>>> Can we name design document with only map/reduce functions as >>>> CouchApp? >>>> No, because it's just a secondary index. >>>> >>>> Can we name design document with all of design functions as >>>> CouchApp? >>>> No, because it's still just a design document, not an application. >>>> >>>> What is CouchApp? >>>> At first, answer is it's name: it's application. Applications has >>>> an >>>> UI. UI in context of CouchDB is provided by HTML. Deisgn documents >>>> may >>>> provide HTML UI via design functions and via attachments. >>>> >>>> So design document where show/list functions produces HTML output >>>> is a CouchApp? >>>> No, it's just a design document where show/list functions formats >>>> result as HTML. >>>> >>>> Then, may be design document with HTML attachments is a CouchApp? >>>> No, it's still just a design document with HTML attachments. >>>> >>>> So what is CouchApp is? >>>> Again, the answer is in the name. CouchApp. Couch, App. CouchDB >>>> Application. With first word everything is clear I hope (: >>>> Application is not only an UI, but also uniform and consistent >>>> logic >>>> about solving some single and specific problem. >>>> >>>> What's the difference between design document with views, shows, >>>> lists >>>> functions, HTML attachments and CouchApp Blog? >>>> The latter is used to implement blog application. The former is >>>> just >>>> an abstract design document with no specific purpose. >>>> >>>> So, if we draw Object Oriented model of CouchApps we'll see pretty >>>> clear structure: >>>> >>>> class JSON(object); >>>> pass >>>> >>>> class Document(JSON): >>>> pass >>>> >>>> class DesignDocument(Document): >>>> pass >>>> >>>> class CouchApp(DesignDocument): >>>> pass >>>> >>>> >>>> So, CouchApp is just a next step in line which is a JSON Document, >>>> but >>>> which the main difference: it solves specific business problem and >>>> provides an interface for users to interact with! >>>> >>>> Can regular documents be CouchApps? >>>> No, because they cannot carry any logic on board. >>>> >>>> Can arbitrary design document be CouchApp? >>>> Technically yes, but no since design documents has no specific >>>> purpose >>>> from the start. CouchApps has that. >>>> >>>> So here is everything is clear for me. You can name CouchApp >>>> whatever >>>> you like: CouchDB hosted application, Design Document application, >>>> Smiley Upplication, but you cannot change next things: it's a >>>> design >>>> document, it serves for specific purpose which makes it an >>>> application. >>>> >>>> Has it CommonJS modules or, not, contains it static Javascript >>>> files >>>> or not, interacts it with the other design documents / couchapps or >>>> not - all these are just an implementation details. >>>> >>>> -- >>>> ,,,^..^,,, >>> >>> -- >>> Professional Support for Apache CouchDB: >>> http://www.neighbourhood.ie/couchdb-support/ >>> >>> > > -- > Professional Support for Apache CouchDB: > http://www.neighbourhood.ie/couchdb-support/ >
