Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: marketing@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: <E4EB88F1-E7D5-4568-8855-148903C588D3@b2w.com>
References: <27218444.284.1430923015159.JavaMail.Joan@RITA>
	<D14FB95B-C6D3-4BFA-BFF3-D8A2584BD038@apache.org>
	<E4EB88F1-E7D5-4568-8855-148903C588D3@b2w.com>
Date: Thu, 7 May 2015 08:00:40 +0200
Message-ID: 
 <CAPMhwa7TmsH5fm3EwkDPpw9VAVGQj+zfOu=6qa6yF6aZPWrpDw@mail.gmail.com>
Subject: Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB
 Articles, Pills and Tutorials Ideas)
From: Giovanni Lenzi <g.lenzi@smileupps.com>
To: marketing@couchdb.apache.org
Content-Type: multipart/alternative; boundary=90e6ba6148d2acc34e051577a149

--90e6ba6148d2acc34e051577a149
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Johs your pattern is great.. is the same we would like to expand with our
tutorials.

Coming to the concept.. to me couchapps are more than a specific pattern,
which can be seen as implementation detail.

There is plenty of patterns on couchapps, less and more complicated, but
this is only great!! it's up to the developer to choose the one which fits
best his own use case, but we should explain him where they differ. Maybe
people sponsoring these patterns(caolan, johs, others?) can do it. At
Smileupps we are just trying to do it.

To me the couchapp term should simply and generically refer to an app
stored, served and running inside couchdb... nothing more
 Il giorno 07/mag/2015 05:44, "Johs Ensby" <johs@b2w.com> ha scritto:

> To get back to the conceptual and storytelling side of this=E2=80=A6
>
> I buy Alexander=E2=80=99s
> > On 06 May 2015, at 14:23, Alexander Shorin <kxepal@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/ logi=
c)
> 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 the=
re
> 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 ve=
ry
> well can reside in several databases.
>
> A one-database-per-user or one-database-per-role approach with common dat=
a
> 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 patter=
n
> 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 <jan@apache.org> wrote:
> >
> > Good reminder, thanks Joan!
> >
> > I=E2=80=99d say as long as we are discussing the marketing angle, thing=
s
> > 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 <wohali@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" <jan@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=E2=80=99s 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 =E2=80=9Chow to fix CouchApps=E2=
=80=9D, which we
> >>> should continue to figure out.
> >>>
> >>> I=E2=80=99d also like push towards thinking about how the CouchApp (o=
r
> >>> whatever the final name might be) story fits into the larger CouchDB
> >>> story of =E2=80=9CData where you need it.=E2=80=9D =E2=80=94 Not nece=
ssarily how the slogan
> >>> made be =E2=80=9Ctrue=E2=80=9D in the context of CouchApps (e.g. =E2=
=80=9CData (and logic)
> >>> where you need it.=E2=80=9D, but more:
> >>>
> >>> - CouchDB=E2=80=99s core feature is geographically distributed replic=
ation.
> >>>
> >>> - Replication becomes really powerful with projects like PouchDB and
> >>> TouchDB that take individual user data offline on their browsers and
> >>> phones.
> >>>
> >>> - The industry=E2=80=99s current battle is vendor-lock-in with propri=
etary
> >>> 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=E2=80=99t think that last bit helps paint the big picture Couch=
DB story
> >>> at all. Granted, I=E2=80=99m making a deliberately weak attempt of ty=
ing
> >>> things together (because I don=E2=80=99t know any better), but this i=
s to
> >>> get you thinking about how this could fit in our larger narrative,
> >>> if at all.
> >>>
> >>> My current thinking is that we can=E2=80=99t make it clear and thus s=
hould
> >>> figure out a plan to retire =E2=80=9CCouchApp=E2=80=9D, while still a=
llowing all the
> >>> cool tech, and find a new name for the concept that can live on
> >>> without making CouchDB=E2=80=99s 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 <kxepal@gmail.com>
> >>>> wrote:
> >>>>
> >>>> On Wed, May 6, 2015 at 3:15 PM, Johs Ensby <johs@b2w.com> wrote:
> >>>>>> On 06 May 2015, at 13:55, Giovanni Lenzi <g.lenzi@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 =E2=80=9Capp=E2=80=9D as a combinati=
on 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/
> >
>
>

--90e6ba6148d2acc34e051577a149--