Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of nslater@tumbolia.org
 designates 209.85.223.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJNb-9qoBaKEi105=4QfK-0NKYwMa-ysc0OCq4h5RKZu=hOW_A@mail.gmail.com>
References: 
 <CAJNb-9p5+oWTqMrYXwvkHyFnuHn-Fg_RNHyLAexuX7LcNMV-gg@mail.gmail.com>
	<D9235C8A8D2B42C7B042ABBB28080C4A@cloudant.com>
	<CA+Y+444P9u73tuWJjx34R1uYb7bcW0DWAhGfGjBEiAUrms9hTQ@mail.gmail.com>
	<CAJNb-9qoBaKEi105=4QfK-0NKYwMa-ysc0OCq4h5RKZu=hOW_A@mail.gmail.com>
Date: Mon, 24 Sep 2012 12:03:07 +0100
Message-ID: 
 <CA+Y+445A0Jcd+iJCSs-p34suX5m1DCYos0X36asnjydJK7-JSQ@mail.gmail.com>
Subject: Re: Part2: What's up dev? About couchapps.
From: Noah Slater <nslater@tumbolia.org>
To: dev@couchdb.apache.org
Content-Type: multipart/alternative; boundary=bcaec5396b50cd3e2f04ca70880a

--bcaec5396b50cd3e2f04ca70880a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Your mail amuses me.

In the first bit you say we have Futon as a CouchApp but no way to
bootstrap it in the build.

Then in your next bit you ask why we'd need Erica in the source. ;) ;) ;)

If Erica is:

* Dead simple, and
* Lets you bootstrap CouchApps without any attendant fuss/framework, and
* Could be used as a library or tool in big/more complex tools

Then why not merge it in and make it official?

On Mon, Sep 24, 2012 at 12:00 PM, Benoit Chesneau <bchesneau@gmail.com>wrot=
e:

> On Mon, Sep 24, 2012 at 12:53 PM, Noah Slater <nslater@tumbolia.org>
> wrote:
> > Making Futon a CouchApp would be a great first step.
> >
> > Other good first steps would be trashing couchapp.com and redirecting t=
o
> > c.a.o/couchapp like you say.
> >
> > Also, creating apps@couchdb.apache.org or similar, to indicate a more
> > official, and broad, focus.
> >
> > If we made Futon a CouchApp, how would that work?
>
> Dale already did it if I remember. But we need a way to bootstrap it.
> I've did it in refuge sometimes ago using part of erica code which is
> in Erlang.
>
>
> >
> > I appreciate the diversity in CouchApp tools, but what I really want is=
 a
> > dead simple way to do it without external tools.
> >
> > Maybe even if that's just a simplistic reference implementation of a
> > CouchApp uploader that we ship.
> >
> > Something other tools could even hook into maybe?
>
> well on that purpose erica is dead simple and in erlang. But I don't
> think we need it. A couchapp is basically design doc... What would do
> this tool?
>
> >
> > (We could then use this to bootstrap Futon from within the build.
> Awesome!)
> >
> > On Mon, Sep 24, 2012 at 11:22 AM, Simon Metson <simon@cloudant.com>
> wrote:
> >
> >> Hey Benoit, all,
> >>
> >> I agree that this isn't about tools. The tools themselves are simple,
> and
> >> the last change to CouchDB that effected CouchApps would be in 0.10.0.
> >> While there are bugs, the tools are relatively stable and usable. I
> think
> >> diversity is good here.
> >>
> >> There's a lot of bad documentation (e.g. wrong) out there. Examples th=
at
> >> are out of date using code that is no longer supported. There seemed t=
o
> >> have been a perception for a while that a couchapp had to use evently,
> for
> >> instance, long after evently had ceased development. I'm not sure what
> the
> >> apache community can do to clean up those issues in the wider world
> (aside
> >> from notifying owners of broken examples) but we could certainly make
> >> things clear on http://couchdb.apache.org and the wiki.
> >>
> >> If possible I would redirect couchapp.org into
> >> http://couchdb.apache.org/couchapp or similar (as couchdb.org does) an=
d
> >> make that a landing page for building applications using CouchDB. Simp=
le
> >> examples in a bunch of languages using idiomatic code would be good.
> >> Highlighting that a web app talking to CouchDB is a simple thing that
> >> doesn't need masses of boiler plate code would be nice, too.
> >>
> >> Mongo got a bunch of press off the back of Meteor (
> http://www.meteor.com/)
> >> which isn't much more than what is already offered by CouchApps, just
> >> better packaging (and some nice hot swappable code). If we want to
> continue
> >> down the road of "CouchDB as an application server" then eating our do=
g
> >> food an making Futon a CouchApp would be a nice start.
> >>
> >> I'd be wary about decoupling the development of "app engine like
> features"
> >> from the database, though. There are features that impact on database
> >> behaviour and need to be considered in the bigger picture. That said, =
I
> >> don't think I've seen any discussion of new features pertaining to cou=
ch
> >> apps for some time (and I'd like to!) and my initial objection depends=
 a
> >> lot on what those app features are.
> >>
> >> The timeline/release schedule stuff that was discussed in Dublin seems
> >> like a good way to mitigate concerns about different pace between
> database
> >> development and app engine work, too.
> >>
> >> Cheers
> >> Simon
> >>
> >>
> >>
> >>
> >> On Monday, 24 September 2012 at 10:21, Benoit Chesneau wrote:
> >>
> >> > Couchapps.
> >> >
> >> > This isn't about tools. I think what @nslater experienced is the lac=
k
> of
> >> > clear direction coming partly from frustration from some devs, and t=
he
> >> > need for some to act in competition with other tools. Today what is
> the
> >> > situation:
> >> >
> >> > - couchapp.org (http://couchapp.org) I ask since a long time to have
> >> the control on this
> >> > domain so I can put new doc (and not specific to couchapp the tool) =
.
> >> > Same for the irc channel.
> >> > - couchapp ml even if we said long time ago that this is a generic m=
l,
> >> > some think that this is the ml for the tool. Which isn't and never
> >> > had. Anyone can speak on it.
> >> >
> >> > Also I wouldn't say that the concept is obscur or so. I can say that=
 a
> >> > lot around are using them quietly in their business. Without asking
> for
> >> > more.
> >> >
> >> > Clearly we need to provide more directions for people. But I would
> like
> >> > to keep the diversity in tools. Just like for clients. Let the users
> >> > choose but don't support one more than the other. This is why each
> time
> >> > it was discussed on the ml or during events the idea of adding a too=
l
> as
> >> > a sub project was abandonned. But we should definitely provide more
> help
> >> to
> >> > others. A good start would be linking them to the tools and their do=
c
> >> > if any. Then the users will choose.
> >> >
> >> > For me couchapp.org (http://couchapp.org) should be a website
> defining
> >> what is a couchapp ,
> >> > how does it works (fundamuntal for shows, lists, ...) then link the
> user
> >> > to different tools. Each tools have their own usages. For users
> >> > couchapp , erica as generic tools, kanso for those who want a
> >> > specific framework, other frameworks around (there are some coming,
> some
> >> > private...) . Maybe it can also be arecipe place. We should link to
> >> > tother when they speak about couchapps. I'm volounter for that.
> >> >
> >> > In summary let take the control back on couchapp.org (
> >> http://couchapp.org), the ml and IRC and
> >> > start to build a communauty feeded by different tools & experiences.
> >> >
> >> >
> >> > As a couchdb developer perspective I also want to split the couchapp
> >> > engine from the rest so we can improve it quietly and maybe have
> >> > different release cycle too. The couchdb would still embed a stable
> >> > version when it's released as well. It could defenitely speed the
> >> > development and will help to includes more users' oriented features.
> An
> >> > app engine need to have a shorter release cycle compared to a databa=
se
> >> > obviously.
> >> >
> >> > Voil=E0,
> >> >
> >> > Hope This mail can launch the discussion and we can start to act. Mo=
re
> >> > important let's the energy come back.
> >> >
> >> > - beno=EEt
> >>
> >>
> >
> >
> > --
> > NS
>


--=20
NS

--bcaec5396b50cd3e2f04ca70880a--