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 <
[email protected]> 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 <[email protected]>
To: Dirkjan Ochtman <[email protected]>
CC: Gregory Kelleher <[email protected]>, Saptarshi Purkayastha <[email protected]>, Matt Adams
<[email protected]>, SurajitNundy <[email protected]>, Daniel Pepper
<[email protected]>, SharathHangal <[email protected]>, Roger Friedman <[email protected]>
On 21/10/11 07:53, Dirkjan Ochtman wrote:
On Fri, Oct 21, 2011 at 04:23, Gregory Kelleher<[email protected]> 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
