incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@tumbolia.org>
Subject Re: Part2: What's up dev? About couchapps.
Date Mon, 24 Sep 2012 11:07:27 GMT
I actually had not heard of Erica before today, Benoit. Perhaps this is
part of the problem??

Like most users, all I know is what I happen to bump in to and try. This
weekend it was Kanso. A while ago it was some other thing.

Let's make sure that the first thing a user bumps in to is a
reference implementation that is known to work, and has docs, and promotion
on the main site.

I don't think we should be choosing tools, no. And I don't think we should
be shipping HTML5 frameworks.

I'm talking about a reference implementation. Something dead simple.

Something that would be enough for Futon, and would be enough to demo in
the docs.

On Mon, Sep 24, 2012 at 12:04 PM, Benoit Chesneau <bchesneau@gmail.com>wrote:

> On Mon, Sep 24, 2012 at 12:57 PM, Noah Slater <nslater@tumbolia.org>
> 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.
> >
> what is broken in couchapp and erica? I Would be pleased to fix it.
> Also couchapps is not kanso. Kanso is one of the tool around.
>
>
> > 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.
>
> I think we can organize the community/ But I'm all to not choose one
> tool over others. Instead we should help any tool author to build
> their own. I would dream to have a couchapp framework in sidedeck, or
> other HTML5 apps framework. But rather than providing a tool I would
> either:
>
> - document the concept,
> - propose a clean way to embed couch
> - improve the api for their needs
> - help the author when needed.
>
> - benoît
>
>
> >
> > On Mon, Sep 24, 2012 at 11:53 AM, 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
> to
> >> 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?
> >>
> >> 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 <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
> 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
> >>
> >
> >
> >
> > --
> > NS
>



-- 
NS

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