On 9/8/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
: What's the usecase here, and the downside to having to provide the : full fq list in the URL? : Is this simply to shorten the request URLs? The main use case is to allow configuration of a requestHandler that the clients don't have to be aware of at all it "just works" ..
That sounds fine then for things that are optinally appended, but not being able to override that doesn't make sense unless it's for some security purpose. Although inStock:true makes sense as a default, it doesn't make sense not being able to ask about all items or items that aren't in stock if you need to. The convenience of not having to know about some of the params (and providing them by default), is much different than locking things down by always adding those params.
: Of course once you make it so that something is always appended, that : will annoy someone else who wants to completely override it :-) True -- but that becomes a decision the person defining the configs can make. If they want it to be overridable they put it in a "defaults" list as they can now, if they want it to allways be appended to the query params they can put it in a (new) seperate list.
Parameters that must always be appended seem to be the exception rather than the rule. But if that's the only mechanism to provide good defaults for appendable lists, people might use it and unnecessarily lock down the view of their data, even if it's not what they *really* meant to do.
ignoring the issues of URL escaping and what exactly it would look like, something that would allways be possible if we add a method to SolrParams get all param names (HttpServletRequest already has this) but it puts the power in the hands of the client generating the request -- what i'm suggesting is putting more power in the hands of the people configuring the index.
Does that make sense (putting the power in the index config) for anything other than security filters?
There's certainly no reason we can't do both -- what you're describing would just affect the relationship of the request params with the <lst name="defaults"> when they get bundled into a DefaultSolrParams; what i'm describing would be the relationsihp between *that* set of params and a new "<lst name="appended"> set.
I guess I'm still not understanding the usecases... If one has defaults that can be appended to, when would one use <appended>?. Security filters would normally be added at a higher level based on user-id or something, *or* could be based on custom logic in a custom request handler. -Yonik
