incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Carlson <lancecarl...@gmail.com>
Subject Re: show/list
Date Thu, 14 Nov 2013 21:03:23 GMT
> Outside of the browser case, the need to present data with specific
structure, filtering, and context is a real feature. Usually I manage
to produce views if I need specific processing to be done. From my
point of view the current show/list implementation fits this case
poorly. I'd prefer to talk about the problem being solved rather than
starting with a solution and finding a problem to keep it around.
There might be a great way to get show and list to fit these needs or
there might be an entirely new API.

What did you have in mind?

> One example where we don't have good solutions and force the client to
do lifting is conflict handling. A show implementation that could do
merges on read could be very useful IMO.

+10

> [0]: Benoit's work on event source support is a great example of
making it easier for browser based clients to interact more seamlessly
with CouchDB. CORS is another area where CouchDB is pushing away the
need for middle tiers. I don't see show and list as a good way to
remove rendering as a tier. Browser-side rendering seems superior in
every way except SEO.

Do you have any ideas on how we deal with SEO? Revert back to the middle
tier?




On Thu, Nov 14, 2013 at 3:58 PM, Tim Black <tim@alwaysreformed.com> wrote:

> On 11/14/2013 02:46 PM, Kevin Coombes wrote:
> >
> > On 11/14/2013 3:34 PM, Alexander Shorin wrote:
> >> On Fri, Nov 15, 2013 at 12:06 AM, Filippo Fadda
> >> <filippo.fadda@programmazione.it> wrote:
> >>> On Nov 14, 2013, at 8:08 PM, Alexander Shorin wrote:
> >>>
> >>>> On Thu, Nov 14, 2013 at 9:58 PM, Filippo Fadda
> >>>> - Provide different from JSON response to clients: browsers,
> >>>> non-couchdb clients (mostly xml driven), etc.
> >>> You can do them in PHP or Ruby. In Rails you need 2 lines of code.
> >>> I'm not gonna to expose my database just to serve some different
> >>> client, all the urls are handled by a web server and I will serve
> >>> any client from the web server. Security, consistence, scalability.
> >> Why I do need PHP or Ruby, when CouchDB is able to do the same without
> >> them?(: Having yet another technology in whole system only raises his
> >> complexity and reduced fault tolerance.
> >>
> > +10.
> >
> > I really like the idea of couchapps using JavaScript (frameworks) in
> > CouchDB. There are then only two moving parts: the browser and the
> > database, with no middleman to complicate matters.
> Same here.  So far the following does everything I need for a web app:
>
> HTML <--> Mustache/Backbone/etc. <--> CouchDB <--> NodeJS
>
> This is a couchapp setup.  So all HTML except index.html is produced
> client-side.  Lists are useful for RSS feeds or the like.
>
> Hoodie's (http://hood.ie) single database per user with filtered,
> authenticated replications to a global share database looks like it will
> solve most of my security needs.
>
> Tim
>

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