couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Wed, 06 May 2015 15:05:22 GMT
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 <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’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 <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 “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/


Mime
View raw message