On Fri, Nov 21, 2008 at 8:25 AM, Paul Davis <[EMAIL PROTECTED]> wrote: > Chris, > > I've got the next 5 days or so free to do some work. I was thinking > about tearing into the view generation, but I wanted to check and see > if you had any pressing plans for it so we're not duplicating work. >
I don't think I'll be jumping on that code this week, but there's some interesting stuff in the pipeline to know about. > Also, if you had any more thoughts on how to implement things that I > should start thinking about let me know. So I met with Francesco from Erlang Training and Consulting, and described to him the selective receive loop thing going on in the view_group_server. He said "ahhh", because he's seen that pattern lots of times, and then said "you never want to be dealing with raw ! and receive". He's sending me some materials about the pattern, so when I have that, maybe I'll know how to build it in the classic Erlang way. Feel free to do any implementation you'd like, but I might suddenly have a flash of insight once I read his material. > > Also, we never quite resolved the what to do during the initial build. > IIRC, it basically boiled down to: Wait no matter what during the > first build vs. never wait. I'm fine to post it to the list (just gonna go ahead and cross post it), but I'm still pretty sure that it's not really possible to do the "never wait" b/c you'll definitely have to wait a tiny bit, if the view is almost up to date. (And how can you tell if the view is very out of date vs only a little? Even on initial generation, you may only have 10 documents in the db, so doing something other than waiting is gonna be more confusing that helpful.) I think the robust solution is to support a status call, that tells you the last sequence id of the view, as well as the current sequence id of database. If an application commonly encounters long view build times than developers could use the status call to provide progress indicators. I don't think it's good to have a normal view request magically turn into a status request, in lieu of waiting on the view build. > What do you think about posting the > question for a vote on the dev list to resolve it? I think either > implementation would be fine as long as we're sure that's what people > expect from the feature. > Matt Aimonetti at QCon in SF this week requested an interesting feature: Etags on view results. In thinking this feature through I realized that it requires the same infrastructure that "update-false" and view status need. Etags would be a function of the view-group signature, a canonical representation of the view server params, and the last-sequence-id that the fully-up-to-date view was emitted to at. So the view state server should be able to return that information as part of the status request, for internal (etag) use as well as for the explicit status api. -- Chris Anderson http://jchris.mfdz.com
