On Tue, Jan 13, 2009 at 3:18 AM, Chris Anderson <jch...@gmail.com> wrote: > On Mon, Jan 12, 2009 at 11:38 PM, Paul Davis > <paul.joseph.da...@gmail.com> wrote: >> On Tue, Jan 13, 2009 at 2:27 AM, Chris Anderson <jch...@gmail.com> wrote: >>> On Mon, Jan 12, 2009 at 11:08 PM, Ulises <ulises.cerv...@gmail.com> wrote: >>>> +1 on render >>>> >>>> The other thing I think we must think about, since we're discussing >>>> naming here, is that I'd hate to have two different names one for >>>> show_docs and one for show_views. From a user's point of view, I >>>> wouldn't care really whether the info I'm looking at came from >>>> _show_docs or _show_view. >>>> >>>> _render is good IMO. >>>> >>>> /db/_view/_render/as_foo >>>> /db/docid/_render/as_foo <- (I must confess I haven't looked at the >>>> whole _show feature in details so some things I say may be way off) >>>> >>> >>> When we were discussing names on IRC, _render came up, but we liked >>> _show better. I think mostly because it was shorter, but I think it >>> also gets across the side-effect free nature of the functions pretty >>> well (not that _render doesn't.) _render is basically fine... I do >>> think I like _show and _list as a pair better, but I'm not set on them >>> by any means. I think we'll need them to be different names, the >>> question is whether they should be related, like _render_one and >>> _render_many or if its fine to be a little more relaxed, like _show >>> and _list. >>> >>> Something worth clearing up about my example. It would be bad form to >>> have a function called "by-html" and I probably shouldn't have used it >>> as an example. The better way to go would be a function called >>> "blog-posts-by-date" which can satisfy client requests for >>> "application/atom+xml", "application/rss+xml", and "text/html". This >>> switching on Accept header is already implemented for doc show >>> functions and demonstrated in the test suite. >>> >>> As far as paths go, there are various good reasons we should stick to >>> the /db/_the_feature_name/... and not /db/.../_the_feature_name >>> >> >> But give us a couple words on why _the_doc_feature needs to be >> different than _the_view_feature >> > > Mostly because you use them for different things. If you're a client > library, it'd be nice to know that the view query options apply to > path A, and the doc query options apply to path B. > > Also I think having different names will make it easier to work with > them, talk about them, etc... they are different functions, after all. > Even if we could squeeze both into the same name space, it doesn't > feel very relaxing. >
Definitely good points. I was mostly concerned about the slash escaping ambiguity and you make a good argument even without implementation references. I'm sold. > -- > Chris Anderson > http://jchris.mfdz.com >
