hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [jira] Commented: (HTTPCLIENT-711) bad route computed for redirected requests
Date Thu, 13 Dec 2007 11:09:03 GMT
On Thu, Dec 13, 2007 at 11:59:16AM +0100, ossfwot@dubioso.net wrote:
> Hi Oleg,
> 
> > consider making changes 
> > to HttpRoute API too? I personally profoundly dislike boolean parameters, as 
> > I never manager to remember what is true and what is false in each particular 
> > case. Three boolean parameters in a row just kill me. Could we use 
> > enumerations instead or some such?    
> 
> You mean an 8-value enumeration? I'm afraid that
> would mean to compute all three booleans, convert
> them into the appropriate enum value (maybe have
> a helper method for that with three boolean args?)
> and converting that value back into three booleans
> in the constructor.
> I don't like the API either, but those are three
> boolean properties which are mostly independent.
> I already added a convenience constructor with a
> single boolean to cover the two most common cases:
> - not tunnelled, not layered, insecure (HTTP)
> - tunnelled, layered, secure (HTTPS)
> 
> But a route needs to be able to specify that a
> plain HTTP connection should be tunnelled anyway,
> or that it should be considered secure. I also
> see a need to allow for layered (HTTPS) connections
> that are not considered secure. The only hard
> dependency is that a connection needs to be tunnelled
> in order to be layered. So we'd need 6 out of the
> 8 possible cases.
> 
> I'm open to suggestions, of course. Maybe an
> enum for PLAIN, TUNNELLED, TUNNELLED_AND_LAYERED
> plus an extra boolean for the secure flag?
> 
> cheers,
>   Roland
> 

Something as trivial as that should already be an improvement in my
opinion: 

enum ConnSecurity {
  PLAIN,
  SECURE
}

enum ConnTunneling {
  DIRECT,
  TUNNELED
}

enum ConnLayering {
  SIMPLE,
  LAYERED
}

or some such?

Oleg



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

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


Mime
View raw message