On 11/20/06 7:22 PM, "Fuad Efendi" <[EMAIL PROTECTED]> wrote: > This is just a sample... > > 1. What is an Error? > 2. What is a Mistake? > 3. What is an application bug? > 4. What is a 'system crash'?
These are not HTTP concepts. The request on a URI can succeed or fail or result in other codes. Mistakes and crashes are outside of the HTTP protocol. > Of cource, XML-over-HTTP engine is not the same as HTML-over-HTTP... > However... Walter noticed 'crawling'... I can't imagine a company which will > put SOLR as a front-end accessible to crawlers... (To crawl an indexing > service instead of source documents!?) XML-over-HTTP is exactly the same as HTML-over-HTTP. In HTML, we could return detailed error information in a meta tag. No difference. If something is on HTTP, a good crawler can find it. All it takes is one link, probably to the admin URL. Once found, that crawler will happily pound on errors returned by 200. XSLT support means you could build the search UI natively on Solr, so that might happen. Even without a crawler, we must work with caches and load balancers. I will be using Solr with a load balancer in production. If Solr is a broken HTTP server, we will have to build something else. > I am sure that mixing XML-based interface with HTTP status codes is not an > attractive 'architecture', we shold separate conserns and leave HTTP code > handling to a servlet container as much as possible... We don't need to use HTTP response codes deep in Solr, but we do need to separate bad parameters, retryable errors, non-retryable errors, and so on. We can call them what ever we want internally, but we need to report them properly over HTTP. wunder -- Walter Underwood Search Guru, Netflix
