we tried last winter to do a couchapp - gave up after never really
getting it to work - forget kanso - forget the "garden" thing someone
mentioned - they are all too complicated
all we wanted was straight forward design docs to load up (no node, no
python, just vim ...) and real good docs to go with that
I do believe that couchapp should be a part of the couch release - it's
both highly integrated and a principal way to use couch - having it
separate means things get out of sync real fast
just my $.02
On 09/24/2012 04:57 AM, Noah Slater wrote:
I also want to clarify my two points in this whole discussion.
You say it's not about the tooling, but that is short sighted. Existing
CouchApp tooling is fractured and broken. The CouchApp website is the
epitome of this. I spent the whole weekend trying to install Kanso, with no
luck, I might add. (Some Node.js incompatibility. I actually gave up.) Saw
on the mailing list that Kanso's maintainer is absent at the moment. Made
me re-think using CouchApps for my personal project. And I'm sorry, but if
I can be put of CouchApps, then I'm sure as hell that regular users are
being turned away weekly by the sorry state of affairs. So yes, the tooling
is important. The tooling is decaying, and that sends a strong message out
to any potential CouchApp developers.
But the other thing is community. We have a CouchApp community, I know it.
I just haven't seen it yet. As Benoit points out, there are a lot of people
probably doing it in private. And small communities forming around specific
tools, and so on. I think we have an opportunity to not only bring *SOME*
of the tooling under our roof, but the *WHOLE* community too. Let's bring
people together.
On Mon, Sep 24, 2012 at 11:53 AM, Noah Slater<nsla...@tumbolia.org> wrote:
Making Futon a CouchApp would be a great first step.
Other good first steps would be trashing couchapp.com and redirecting to
c.a.o/couchapp like you say.
Also, creating a...@couchdb.apache.org or similar, to indicate a more
official, and broad, focus.
If we made Futon a CouchApp, how would that work?
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?
(We could then use this to bootstrap Futon from within the build. Awesome!)
On Mon, Sep 24, 2012 at 11:22 AM, Simon Metson<si...@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 that
are out of date using code that is no longer supported. There seemed to
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) and
make that a landing page for building applications using CouchDB. Simple
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 dog
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
couch 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 lack of
clear direction coming partly from frustration from some devs, and the
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 ml,
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 tool 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 doc
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 database
obviously.
Voilà,
Hope This mail can launch the discussion and we can start to act. More
important let's the energy come back.
- benoît
--
NS
