couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david martin <david.mar...@lymegreen.co.uk>
Subject Re: [discuss] couchapp.org down, couchapp.org spammed
Date Sun, 01 Dec 2013 09:07:12 GMT
On 01/12/13 00:20, Russell Branca wrote:
> In its current form, couchapp.org is a relic that has been mostly abandoned
> and is not maintainable by the community. I strongly feel we should move
> the couchapp documentation into official documentation. I see two relevant
> points of interest in this discussion. First is the notion of couchapps as
> the self contained application platform that utilizes show/list functions,
> and whether these should be included in CouchDB. I don't think this is the
> important issue at hand.
>
> The bigger issue is that the defacto method of defining design documents is
> to use one of the many "couchapp" tools, and the only place this is
> documented as a whole is couchapp.org. This is a disservice to the
> community, and one that needs to be resolved. This is a constant source of
> confusion to new users who quickly realize the futility of defining design
> docs in the browser, and get lost when told "just use a couchapp", and then
> they inevitably end up clicking on the top google result for "couchapp",
> couchapp.org. We need to have this properly documented in the official
> documentation so that the process is fully defined for new users.
>
> A couple of options for approach would be to formalize the folder
> definition of a couchapp and list tools known to be compatible, or to
> officially bless a tool like Erica. While I do want to see Fauxton provide
> powerful editors for all the different function types, I don't think this
> is sufficient as people typically want to keep their design docs raw code
> under SCM. Whatever approach is taken, I think the number one priority here
> is ensuring proper documentation explaining to users best practices for
> defining and maintaining design docs.
>
>
> -Russell
>
>
> On Sat, Nov 30, 2013 at 2:57 PM, Filippo Fadda <
> filippo.fadda@programmazione.it> wrote:
>
>> List and show are not stored procedure. We already discussed that Benoit.
>>
>> http://wiki.apache.org/couchdb/Formatting_with_Show_and_List
>>
>>  From the documentation: "Show and list functions are side effect free and
>> idempotent. They can not make additional HTTP requests against CouchDB.
>> Their purpose is to render JSON documents in other formats."
>>
>> Apples are not pears. I'm not buying it, stop selling list and show like
>> stored proc. A stored procedure, in general, is not side effect free or
>> idempotent.
>>
>>> If you just want a database then any KV is enough for your purpose. If
>> now
>>> you want a DBMS which at least I want, then you probably want a way to
>>> store procedures and such to adapt the query language to your needs.
>> Guess,
>>> what is the purpose of lists and shows?
>> Not in the way they are. To me, actually list and show are useless. I'm
>> sorry, this is what I think. Can we just move on?
>>
>> -Filippo
The reason for my diplomatic controlled aggression ( or rage as you termed it in a rather
cheeky way)
on this "Elephant in the room" subject is because
  "those that refuse to learn the lessons of history are condemmed to repeat the mistakes
ad infinitum"
The essence of responsible open source is to ensure that neophyte users and persons who do
not know any better
are not trapped or even locked-in to endless fruitless toil pushing ordure up hills with pointed
sticks.
Everyone is free to do as they wish in this world, unless what they do is promoting a course
of action which harms others.
People Hate Perl (or PHP or Perl Hypertext Preprocessor) is hardly a platform for a blind
man to be standing upon to make claims of knowing what the Elephant is.
Every-one has different opinions on almost everything including Elephants
"http://en.wikipedia.org/wiki/Blind_men_and_an_elephant"
Here is a diplomatic history lesson that affected many people in a far off land.

-------- Original Message --------
Subject: 	Re: Sending HTML5 forms from iThoughtsHD "Rant on Couchapps"
Date: 	Fri, 21 Oct 2011 10:05:30 +0100
From: 	david martin <david.martin@lymegreen.co.uk>
To: 	Dirkjan Ochtman <dirkjan@ochtman.nl>
CC: 	Gregory Kelleher <greg@kelleher.cc>, Saptarshi Purkayastha <sunbiz@gmail.com>,
Matt Adams <matt.adams@radicaldynamic.com>, SurajitNundy <nundys@gmail.com>, Daniel
Pepper <daniel.pepper@gmail.com>, SharathHangal <sharath.hangal@gmail.com>, Roger
Friedman <rdf4@cdc.gov>



On 21/10/11 07:53, Dirkjan Ochtman wrote:
> On Fri, Oct 21, 2011 at 04:23, Gregory Kelleher<greg@kelleher.cc>   wrote:
>> If you search the web for info on your own, you'll want to first be clear about the
terminology.  In particular, "CouchDB" is the name of a top-level Apache Foundation project
and of the non-SQL DBMS it distributes as its open source product.  A search on that term
should reveal broad activity, volunteer and commercial development, professional training,
and both free and subscription hosting services.
>>
>> In addition to being a JSON document DBMS, CouchDB can function out of the box as
a Web applications server and deployment server.  The first O'Reilly book on CouchDB coined
the term "couchapp" as a name for the distinctive 2-tier Web applications that can be creates
with the new technology.  They also named their utility functions used to create these web
apps "couchapp".
>>
>> There are now several competing utility functions used by many to help with development
of CouchApps, and a few of them are named the same, creating some confusion.  It seems you've
been investigating one of these scripts.  Most of them are pretty simple, which accounts for
the low commit rate.
> I'm aware of all this, though I admit to not having tracked all the
> different utilties that can help with building couchapps (the 2-tier
> apps). Still, do you know of any larger projects that are built
> according to the 2-tier architecture? It seems to me most are more in
> the proof-of-concept, play-thing, experimental kind of way. I used to
> track Mozilla's Raindrop, which was built as a couchapp, but it was
> discarded at the experimental stage because they thought CouchDB was a
> bad fit for their data model.
>
> Cheers,
>
> Dirkjan
>
>
Current reasonably Informed opinion in Couchdb user list favours  2.5-tier architecture
with  memory resident njinx load balancing and proxying multiple couchdb databases.

Some aspects of the total need can be catered for by simple couchdb hosted client side
so called couchapps. This is the preferred solution for stateless applications such as
viewing data from a database or Create Update and Delete.
Couchdb is based strictly on HTTP which is a stateless protocol,
So ipso facto all Couchdb so called couchapps are strictly stateless and thus can never form
the whole of a so called "larger project". They should however be used whenever possible
and the fact that they cannot be used in certain circumstances alerts designers to the
fact that they are implicitly assuming a state in their design and that has implications
that are often ignored because it is hidden in the tiers they don't even know exist.

If you do have massive statefull applications, then there is a very comprehensive
layer for this very purpose for example see Couchbase Server 2.0 which uses Membase
and Memcached. In most cases this would be overkill, and changes feeds to user modules
of CouchDb can provide a useful 0.5 adjunct to the strict 2-tier model.

Finally on the subject of  couchapp can do this and couchapps cannot do that and that couchapps
activity is low, may I say that couchapp was and is the first helper framework to create
applications run on clients and served from CouchDB.  Couchapp is a Python based helper application.
Couchapp (the Python helper application) is now on its last release and will be replaced by
Erica which is native Erlang and therefor removes dependancy for Python. (Erlang is always
present for CouchDB).
Couchapps run on a client and are served by CouchDB.
This is a generic term to encompass applications that can use any language known to the browser
in their
implementation, (including Javascript produced by Google Closure Templates),
or indeed anything that you can run client side in a browser.
In conclusion, to attribute facts to couchapps you must attribute them to
the browser languages, the DOM, CSS or html or xhtml or any client technology or so called
framework that forms the HTTP web.

Yours sincerely,
David Martin






-- 
David Martin


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message