Firstly, let me thank you all on the great work you have done with
couch. Thanks.
Secondly, regardless of JChris/domain ownership/personal likings etc;
Is there any possibility of improving (or changing) couchapp (or its
replacement's) functionality?
For example:
1. Javascript stored on the file system must match the javascript stored
on couch (i.e. no including common code through comments in view files)
- this is required if you want reliable version control - and be able to
match each code change with behavior change and vice versa.
2. Support unit test and profiling support (or at least permit them
without having to modify the code managed through couchapp). There has
been quite a bit of work on unit tests/linting tools etc, and the way
couchapp works makes it difficult to take advantage of these.
Of course these are my desires - and I understand you and others may not
share it. And you have my apologies in case any of these topics are
discomforting in any way.
I will shut up now.
Thanks
Vivek
On 12/02/2013 05:35 AM, Andy Wenk wrote:
why don't we stop the discussion here and think about how couchapp.org or
at least the contents can be maintained further? There are only some points
to clarify:
- do we (the CouchDB community) want to maintain the contents? Regardless
if it is "part" of CouchDB or not (this is a never-ending discussion imho)
- who will start to speak with JChris about the domain?
- where do we want to host the domain or contents?
I have a personal interest to keep couchapp.org and / or it's contents
running because that was my first contact with CouchDB, Benoit and JChris.
I don't want to see the awesome work die!
Cheers
Andy
On 2 December 2013 02:50, Vivek Pathak <[email protected]> wrote:
Hi
I agree quite a bit about the coucapp. Hence couldnt help but comment.
Couchapp does seem to have quite a few rough corners feel to it - when
compared to the soundness of couchdb as a whole (even without bigcouch etc).
I have been using a self written tool to push view/list/show code to
couchdb from using a makefile for my project. A sample line from the
makefile is as follows:
belongs_view:
update_field.py -u $(COUCH) $(DBNAME) _design/ids views.belongs.map
belongs.js
This pushes belongs.js to key db["_design/ids"].views.belongs.map ,
recursively creating any intermediate json objects as needed.
It has worked well for me because I get to edit my javascript code in any
editor. And unlike couchapp, I do not need to install a python package
(particularly one which does not seem to have heavy community support).
The use case for couchapp is mentioned as sharing code between views (
http://wiki.apache.org/couchdb/HTTP_view_API#Sharing_Code_Between_Views). At
the cost of adding shared code into common js modules explicitly, I
get the convenience of "what you see is what you get" - unlike the
inclusion of code through JS comments in couchapp.
If the overall idea of having a standalone tool is attractive, I can
surely improve it a bit (eg: usage line can improve, etc) and share more
widely. It anyway was created under an apache 2 licence.
Thanks
Vivek
On 11/30/13, 10:33 PM, Alexander Shorin wrote:
On Sun, Dec 1, 2013 at 4:20 AM, Russell Branca <[email protected]>
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
+1 and actually I'm only waiting for rcouch merge and having erica as
builtin tool. There is already big place to land all the stuff in
source code tree and even named also as "couchapp" since it provides
huge potential for more interesting and rich content rather than just
"ddoc" or similar.
--
,,,^..^,,,
