On Wed, Jan 21, 2009 at 1:03 PM, Christopher Lenz <[email protected]> wrote: > Hey all, > > this thread has long completed, so I'm going to tally up the results. For > every option in (+1, +0, -0, -1) I'll include the number of "votes" in the > form binding/total, where binding votes are those by PMC members. > > On 08.01.2009, at 04:30, Antony Blakey wrote: >> >> 1. Remove the _temp_view facility completely, because you can use a >> temporary _design view, at which point you should understand the performance >> implications, and it cleans up the code. > > +1: 2/6 > +0: 1/2 > -0: 1/1 > -1: 0/0 > > >> 2. Leave it as _temp_view, because it does the equivalent of view >> create/query/delete view in a single POST, and you can document the >> performance issue. > > +1: 2/6 > +0: 1/1 > -0: 1/2 > -1: 1/1 > >> 3. Change it to _slow_view, because compared to _temp_view, the name >> should act as an immediate warning for people who haven't read the >> documentation. > > +1: 1/1 > +0: 1/1 > -0: 1/1 > -1: 2/6 > > > One thing that's clear is overwhelming objection against the renaming to > _slow_view. There seems to be a slight preference towards removing temp > views altogether, but I think that may take more discussion. > > I would suggest we move forward here by first backing out the change to > _slow_view.
+1 This should be an easy change - I'd recommend using find and replace, rather than SVN trickery, because there's been work done since then. I don't mind doing it but I have a deep stack right now implementing view forms. I can do it tomorrow or if anyone else wants to do it now they are welcome. Dropping the feature would push the work of creating temporary design doc to client libraries. I think it would be a simple patch for Futon, but if language libs want to transparently keep working for users who want temp-views, they'll need to write some code. (I think they'd be fine not attempting to implement.) -- Chris Anderson http://jchris.mfdz.com
