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:04:47 GMT
My goal is to have a simple command line tool that can take a directory and
upload it to a design doc. As simple as you can make that while still
having it functional as a basic CouchApp tool. And in a way that could be
used or embedded in other tools, or be used as a reference implementation.

On Mon, Sep 24, 2012 at 12:03 PM, Noah Slater <nslater@tumbolia.org> wrote:

> 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>wrote:
>
>> 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
>> 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?
>>
>> 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
>> 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