incubator-couchdb-dev mailing list archives

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


Well I mailed the ml, twitter and thought every devs was aware about
it. My fault I guess. I'm using it in place of couchapp. Partly
because I distribute it with rcouch. Which is easy because like big
couch, erlang runtime is shipped with rcouch.



>
> 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.

Reference implementation was couchapp at least for the fs for a long
time. And erica is using it. If you want something dead simple some
part of the code could be reused.

To be clear the only reason I'm speaking about erica is because it's
written in erlang and share the same dependencies couchdb is using.
For a good reason, it is shipped with rcouch in some projects . (like
bigcouch erlang runtime is shipped with rcouch as an OTP release).

But again i'm not sure, we should provide a tool vs help the ecosystem
to grow and build tool around.

- benoit
>
> 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
View raw message