Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of bchesneau@gmail.com designates
 209.85.220.165 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=RiS8YHzPBFv5mmeSzPcm7fJxa7Zae2uilzRGv/vDCmTH5VmELHhz0HYFOHvFPAHVhQ
         Aj0pr57CMaoo9DsoS7QJI3jsopkQP6fOCpE51ZvlISRkOpN/ln6Mx+LvWFytyeV7Bmrc
         3jeceRN5vSQ20qBAEF6j4c7THxQjd/F+hN8Mw=
MIME-Version: 1.0
In-Reply-To: <e282921e0902242116n2cd207c4x7a9d0feced3f10d9@mail.gmail.com>
References: <e282921e0902242116n2cd207c4x7a9d0feced3f10d9@mail.gmail.com>
Date: Wed, 25 Feb 2009 17:46:12 +0100
Message-ID: <b7cd8ed10902250846m59908819w2850589fde22673d@mail.gmail.com>
Subject: Re: REST, Hypermedia, and CouchApps
From: Benoit Chesneau <bchesneau@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2009/2/25 Chris Anderson <jchris@apache.org>:
> Devs,

...

> One way to fix this it to give the resources made available by a
> design document a common root. This means we can use hrefs like
> "_show/docid" to link to a show function from an attachment. =A0So we
> get paths like this:
>
> /db/_design/foo/_view/bar?limit=3D10
> /db/_design/foo/_show/docid
> /db/_design/foo/index.html
>
> The downside is that the URLs are longer (and that the change would
> break all clients), the upside is the ability to link from one to the
> other (and thus be part of the web).

Since it allow relative urls i like this schema. I don't thin that url
length is a problem. Urls could be easily rewritten and we may add add
a url resolver that would consider views/shows/lists as endpoint I
guess.

>
> =3D=3D A related question =3D=3D

...

> Currently listing the available apps takes quite a few HTTP requests
> (Futon has to load all the design documents in each DB). If CouchDB
> wanted to support CouchApps more directly, it could provide a JSON
> resource at /db/_design/ that lists all design docs, along with the
> absolute path to their start page, if they have one.

To list all databases I would for the damien's solution, ie a database
that act as a directory . Maybe this directory could be created
dynamically: each time a new design doc is created we could detected a
couchapp property and then add to the directory. When it's
deleted/updated same process ?

- beno=EEt