On Wed, 2008-01-09 at 17:09 +0100, Roland Weber wrote: > Hi Oleg, > > > What if we approached the problem form a different angle and simply did > > away with parameter linking in HttpCore altogether? Hierarchy building > > is used only in a handful of high level protocol classes and always for > > representing an ultra-trivial parent / child relationship. > > > > This would enable us to get rid of a lots of complexity and push the > > decision about the specifics of parameter resolution to out of core to > > higher level modules such as HttpClient. > > That's a change that should be considered by it's own merit. > If you feel that a stack approach would reduce complexity > and not generate too much garbage, go ahead and change it. >
Parameter linking is gone for good. Please review carefully and let me know if you find anything disagreeable. I think this change makes parameter resolution significantly simpler and thus less error-prone. I _personally_ feel quite happy about it. > > This would also render the > > whole 'unsetting parameter' issue an implementation detail each upstream > > project can choose to solve differently. > > Not "can" but "must" choose to solve, or run into problems down > the road. I am not sure I fully agree, but feel free to come up with a solution you would be comfortable with. > And because it isn't addressed in core, every project > needs to solve it differently. > If we implement the "global null value" approach, that should > be done in core so that every project using core can use the > same null for all parameters. If we prefer to deal with the > problem on a case-by-case basis, then it can be done in each > module/component/project that defines a parameter for which > it matters. What I do not want to see is a bunch of projects > that each define a non-global null value just for their own > parameters or HttpParams implementations. > > As mentioned in my other mail, I believe now that the changes > for a global null value in core will be compatible, so this > does not block the release of beta1. > I'll go ahead with cutting the release on Friday provided there are no complaints about the latest change. Cheers Oleg > cheers, > Roland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
