couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <a...@nms.de>
Subject Re: [discuss] couchapp.org down, couchapp.org spammed
Date Mon, 02 Dec 2013 10:35:40 GMT
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 <vpathak@orgmeta.com> 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 <chewbranca@apache.org>
>> 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.
>>
>> --
>> ,,,^..^,,,
>>
>
>


-- 
Andy Wenk
Hamburg - Germany
RockIt!

http://www.couchdb-buch.de
http://www.pg-praxisbuch.de

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

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