I like the idea of getting rid of them. If they can be "emulated" within Futon, then so much the better.
The only thing I could suggest is simply providing tooling to make it easy for folks to create sub sets of existing DBs. That way it's straightforward to encourage development with "permanent" views, but not to do it on production DBs, or production volumes. The curse of the temp_view is that they persist and "work just like" a permanent view, so on the surface folks don't see the difference (and in development, there is, almost, no difference). As an aside, however, a problem with emulating temp views kind of become problematic if/when folks wish to use a different view server than JS. Clearly, it's not practical to emulate a Erlang view server within a JS couch implementation for development. So, that seems to me to point even more to focusing on tooling to make it easy and routine to create "development" databases that people can mold and form. Or to make, say, implicit view version. (Create a view, create it again and the old one is versioned away as view_1 or whatever). This ends up acting "just like" temp views, but now there's a minor Garbage Collection phase to go through and remove the old views. And, again, when this is done on a "throw away" instance of the DB, it's even less of an issue. Regards, Will Hartung
