After reading this<http://blog.ianbicking.org/2008/10/24/hypertext-driven-urls/>a blog post by Ian, I was thinking about how it would apply to Melkjug. In request for /mash returns a list of melk ids, such as "melk:2da0ee77-0f08-17ac-8128-f63babdcd16e"
I'm wondering if the following makes me sense and could give a performance boost in the future: Send back a list of URLs instead of melk ids, or probably a list of tuples with (url, metadata ...). The url would essentially be the melkid placed under some root article url path. For one, this means we don't need to transfer article html in the collapsed view until an item is expanded. In the case of the expanded view it means more client requests, but a load balancing proxy or other such client request entry point could bypass our app altogether and proxy a local request to CouchDB directly. Please weigh in here, because I'm not sure my thinking is correct, but I think this could give us caching advantages at the proxy point. The one concern I have is that article_html is supposed to be returning pretty serious html formatting around the article content. I don't know if there's a way to use CouchDB api to allow an external formatter (and if this partially negates the benefits described above) like a JSON analogue of XSLT. In any case, exposing the raw json of an arbitrary article from the couch (possibly in addition to an html-formatted view) seems to fit nicely into the notion of melkjug-as-service. Thoughts? -Randall
