: Hoss, I apologize for spamming the issue comments. I just thought it : would be the appropriate place to record all critical discussions and : decisions related to the issue so that people who read it later get to : know all arguments made.
it's not a big deal, it's just that SOLR-127 as it stands acocmplished what it set out to do, and the new functionality works as designed. Discussions regarding general future direction of big concepts, and what defaults should be, and things like that really work better on the mailing list ... once concensus is reached, then new issues can be opened and linked to the orriginal one (or summary updates can be posted in the orriginal issue). : 1. Solr Statistics page (statistics change even though index doesn't) youlost me there ... the stats page is a JSP which shouldn't be affected by this change. : 2. Distributed Search (results on another shard may change and this : index remains same) : 3. Partial Results in case of timeouts : 4. DataImportHandler - the status page keeps changing even though the : IndexReader remains the same (until committed) Agreed, these are problems ... but none of these features existed when SOLR-127 was commited :) : I think we both are in agreement that this should configurable on a : per-handler basis instead of on a global basis. I definitely agree that a mechanism needs to exist for RequestHandler subclasses to override the default behavior -- But -- I'm not entirely certain that the cache header behavior needs to be *configurable* on a per handler "instance" basis (ie: that two isntances of FooHandler with differnet names need to be able to have different behavior based on how they are setup in solrconfig.xml) ... if it's easy to support then great, but i don't think we should jump through a lot of hopes to achieve it. : To your point #2, it is true that Solr should be emitting the cache : headers to conform to HTTP spec but, the strategy used to compute : those headers should be varying for different handlers. If we take a Agreed ... but the default behavior when a handler does not specify a strategy (either by explicit ommision or because it predates the cache header functionality in Solr) should be to base it on the index as currently commited. : IMHO, the approach taken by SOLR-505 and SOLR-506 is good enough. So : using, SOLR-505 handlers can decide to emit/suppress cache headers on : a per-response basis (e.g. partial resutls, errors etc.). Using : SOLR-506, the end user can enable/disable emitting cache headers : per-handler. We can emit cache headers as the default behavior for : SearchHandler, SpellCheckerHandler and MoreLikeThisHandler to begin I haven't had a chance to look at either issue (or hte comments/patches in them) yet, bu I agree with you in principle. -Hoss
