don't use temp views

The CouchDB approach is to not use temp views at all, which is why they're being removed; they're very inefficient. Instead, what you need to do is:
1. create a design document with your view in it
2. call that view to get your data

(This is akin to creating a stored procedure and then calling it, rather than making ad-hoc SQL queries, in an RDBMS).

We need to change our API to include the following:

def add_view(view_name, javascript_code, design_doc_id="design")

a function to add a new view to a specific design document (or to a "design" design document if unspecified)

This is really about education: people using our API need to understand that the way to do this properly is to follow the two-step process above, rather than doing ad-hoc temporary queries. The documentation in desktopcouch/records/doc/records.txt needs to be updated to describe this more proper approach, and to show how to test if a design document exists and create it if it does not.

May I suggest that we also add some convenience functions? For example:

def get_records_of_type(self, record_type):
"""retrieves all records of the specified record type"""
 #check for a design doc for a record type
 #if the view is not already there, create it
 #use the view to return the records of that type

Stuart and I discussed this briefly, and I was opposed to implicitly creating views in the database, on the grounds that we may be hiding too much of how couchdb works from the client app developers (also in this case we may be overwriting handcrafted views that the application developer prefers.) Having said that, I'm all for convenience, so how about a compromise:

def get_records_of_type(self, record_type, create_view=False):

I think we do a similar thing already for the database object.

This is a blocker for the first release of desktopcouch, we need to be very careful about not releasing the temp view api and then taking it away after people eagerly wrote apps on top of it.