[HttpCore] Do away with parameter linking was Re: [HttpParams] unsetting a parameter in the hierarchy

[Oleg Kalnichevski <ol...@apache.org>]

Roland et al

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. This would also render the
whole 'unsetting parameter' issue an implementation detail each upstream
project can choose to solve differently. The existing parameter linking
code can be replaced with a trivial two level stack of HttpParams.

Would that solve the problem for you?

Cheers,

Oleg  


On Sat, 2008-01-05 at 10:42 +0100, Roland Weber wrote:
> Roland Weber wrote:
> > how are we going to "unset" a parameter that is defined
> > somewhere higher up in the hierarchy? The example at hand
> > is the default proxy. An application defines a default
> > proxy in the client parameters, but wants a specific
> > request to be sent without the proxy. Setting the value
> > to null in the request parameters doesn't work, since
> > null means "look higher up in the hierarchy".
> 
> This problem is an incarnation of
> https://issues.apache.org/jira/browse/HTTPCORE-65
> 
> > Option A:
> > Define a global "Void" object that can be used to
> > explicitly unset any parameter value. Since the global
> > object does not match the expected type of parameters,
> > the check for "Void" has to be done before casting
> > the value to the target type.
> > Moving the check for the "Void" object into the params
> > implementations will not work, since each param impl
> > can be put into a hierarchy. If it's in the hierarchy,
> > it has to return the object to cancel recursion, only
> > the outmost impl can be allowed to do the null conversion.
> 
> The global Void object could be handled in the type
> specific getter methods, and in static helpers for
> non-default types.
> 
> cheers,
>   Roland
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: [HttpCore] Do away with parameter linking

[Roland Weber <os...@dubioso.net>]

Hi Oleg,

> 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.

Some details (SPS = SimpleParamStack, CPS = ClientParamsStack):

- SPS constructor expects params in child-parent order, while
  CPS constructor expects them in parent-child order
- SPS uses "Param" in the name, CPS uses "Params"

I don't care which way these two are done, but it should be consistent.
I think I chose "Params" for CPS because the interface HttpParams also
has the s, but I don't remember for sure.

- SPS and CPS have slightly different behavior on copy().
  I'm fine with the differing behavior, but the one for SPS should
  be documented too.
- SPS.isParameterSet checks only the child/local params, not the parent.
  If that is the intended behavior, it needs to be documented.
  CPS behaves differently. The interface docs don't say anything
  about local or non-local parameters, I think I deleted that
  stuff recently because it didn't make sense anymore after the
  linking was moved to a separate interface.
- It's worth a JavaDoc (class) comment that the set and remove
  methods will affect the child/local params only. That's also
  the rationale for cloning only those in copy().

> I'll go ahead with cutting the release on Friday provided there are no
> complaints about the latest change.

OK. I'll see whether I can provide a patch for parameter
unsetting this evening. If it goes into beta1, it can be
used by the next client alpha. But that's already assuming
the "global null" approach, which I would have preferred
to discuss first against the other alternatives.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: [HttpCore] Do away with parameter linking

[Oleg Kalnichevski <ol...@apache.org>]

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: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

Re: [HttpCore] Do away with parameter linking

[Roland Weber <os...@dubioso.net>]

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.

> 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. 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.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org