On Fri, Nov 21, 2008 at 1:27 PM, Chris Anderson <[EMAIL PROTECTED]> wrote: > 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. >
Sweet. Unless I have some sudden insight into gen_server and how to make that wait appropriately without that receive loop I won't change the mechanics very much. >> >> 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. > Very good points. I was wondering about how the mechanics of the API would work with the status and turn around times. Your argument here has pretty much convinced me that the stale=ok and status=true is probably the best solution to the problem. >> 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. > I'm not sure on the specifics of ETags, but it sounds like you've covered all the bases that would be required here. > > -- > Chris Anderson > http://jchris.mfdz.com > Anyone else out there have thoughts on view generation?
