You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Roland Weber (JIRA)" <ji...@apache.org> on 2007/07/15 19:18:04 UTC
[jira] Created: (HTTPCORE-101) Consider read-only HttpParams
Consider read-only HttpParams
-----------------------------
Key: HTTPCORE-101
URL: https://issues.apache.org/jira/browse/HTTPCORE-101
Project: HttpComponents Core
Issue Type: Improvement
Components: HttpCore, HttpCore NIO
Affects Versions: 4.0-alpha5
Reporter: Roland Weber
Assignee: Roland Weber
Priority: Minor
Fix For: 4.0-alpha6
Consider turning HttpParams into a read-only interface, moving modifiers to an extension interface.
Suggested by Daniel Müller on httpcomponents-dev.
This will break the following style of updating existing parameters:
xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-101) Consider read-only HttpParams
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513474 ]
Oleg Kalnichevski commented on HTTPCORE-101:
--------------------------------------------
Roland
Generally I feel this is very similar to the mutable / immutable HTTP message interface story we had in the early days of HttpCore. While very nice conceptually the split of interfaces into immutable and mutable versions proved too cumbersome in practice. Likewise I feel we are not gaining that much by making HttpParams immutable per default. Yes, one can do silly things like modifying parameters concurrently from a different thread but there are other wonderful ways of screwing things up very badly. We simply have to state HttpParams are meant to be used in 'write once read many' mode.
I suggest we leave this issue on the back-burner for a while revisit it sometime later this year before HttpCore goes BETA
Oleg
> Consider read-only HttpParams
> -----------------------------
>
> Key: HTTPCORE-101
> URL: https://issues.apache.org/jira/browse/HTTPCORE-101
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
> Fix For: 4.0-alpha6
>
>
> Consider turning HttpParams into a read-only interface, moving modifiers to an extension interface.
> Suggested by Daniel Müller on httpcomponents-dev.
> This will break the following style of updating existing parameters:
> xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-101) Consider read-only HttpParams
Posted by "Daniel Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513701 ]
Daniel Müller commented on HTTPCORE-101:
----------------------------------------
Comments are fine by me. I can understand the concern for splitting the interfaces. When I can find some hints about the correct usages of an API, then that's all I need, be it from code structure or examples/documentation. And your guided tour goes quite a long way to achieve that.
Cheers,
Daniel
> Consider read-only HttpParams
> -----------------------------
>
> Key: HTTPCORE-101
> URL: https://issues.apache.org/jira/browse/HTTPCORE-101
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
>
> Consider turning HttpParams into a read-only interface, moving modifiers to an extension interface.
> Suggested by Daniel Müller on httpcomponents-dev.
> This will break the following style of updating existing parameters:
> xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-101) Consider read-only HttpParams
Posted by "Daniel Müller (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512822 ]
Daniel Müller commented on HTTPCORE-101:
----------------------------------------
The reason for the proposition was that in the code I wrote for httpcompontents 4.0-alpha5, I'm preinstantiate the params in the following way:
Fields:
private final HttpParams httpParams;
...
Constructor() {
...
BasicHttpParams params = new BasicHttpParams(null);
HttpProtocolParams.setVersion(params, HttpVersion.HTTP_1_1);
HttpProtocolParams.setContentCharset(params, "UTF-8");
HttpProtocolParams.setUserAgent(params, "Jakarta-HttpComponents/1.1");
HttpProtocolParams.setUseExpectContinue(params, true);
httpParams = params;
...
}
If the interface would not be modifiable, it would clarify that the params are not really modified by the framework itself. And from this anyone could deduce that this class can be safely be used by multiple threads from a httpcomponents perspective. This is a result of a question posted on httpcomponents-dev [1].
[1] http://www.nabble.com/Threadsafety-of-the-classes-in-core-tf4037548.html#a11470779
> Consider read-only HttpParams
> -----------------------------
>
> Key: HTTPCORE-101
> URL: https://issues.apache.org/jira/browse/HTTPCORE-101
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
> Fix For: 4.0-alpha6
>
>
> Consider turning HttpParams into a read-only interface, moving modifiers to an extension interface.
> Suggested by Daniel Müller on httpcomponents-dev.
> This will break the following style of updating existing parameters:
> xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Closed: (HTTPCORE-101) Consider read-only HttpParams
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Roland Weber closed HTTPCORE-101.
---------------------------------
Resolution: Won't Fix
Fix Version/s: (was: 4.0-alpha6)
I'm marking this as WON'T FIX. We can re-open if we see a case for an improvement.
I'll add a Q&A to the guide.
cheers,
Roland
> Consider read-only HttpParams
> -----------------------------
>
> Key: HTTPCORE-101
> URL: https://issues.apache.org/jira/browse/HTTPCORE-101
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
>
> Consider turning HttpParams into a read-only interface, moving modifiers to an extension interface.
> Suggested by Daniel Müller on httpcomponents-dev.
> This will break the following style of updating existing parameters:
> xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-101) Consider read-only HttpParams
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513235 ]
Roland Weber commented on HTTPCORE-101:
---------------------------------------
With alpha5, Oleg made sure that parameters passed to the framework will be copied so they don't get modified by accident. I don't see how this approach would fit reasonably with a read-only interface. Either you get unnecessary params duplications, or you need ugly read-only wrappers to prevent such duplications. (Assuming that read-only parameters would implement the copyParams() method as "return this".)
I tend to leave things as they are, unless we run into serious problems with it. By serious problems, I mean user feedback that the API is too tricky to use, or performance problems, or other such stuff. Something beyond "it would be nice..."
We know our documentation is lacking, and that includes the parameterization framework. But maybe it's better to address this by writing documentation rather than by twisting the API to require less documentation?
cheers,
Roland
> Consider read-only HttpParams
> -----------------------------
>
> Key: HTTPCORE-101
> URL: https://issues.apache.org/jira/browse/HTTPCORE-101
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
> Fix For: 4.0-alpha6
>
>
> Consider turning HttpParams into a read-only interface, moving modifiers to an extension interface.
> Suggested by Daniel Müller on httpcomponents-dev.
> This will break the following style of updating existing parameters:
> xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-101) Consider read-only HttpParams
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512809 ]
Roland Weber commented on HTTPCORE-101:
---------------------------------------
[collection of thoughts]
There are few places in core, NIO, client et al where parameters are instantiated within the framework and modified outside.
In most cases, it is possible to prepare parameters in advance and pass them to a constructor.
This does not work for AbstractHttpMessage, there is no constructor that takes a params argument.
Change examples to pass params to constructors, or to replace the existing params instead of modifying them.
Create an additional singleton EmptyParams with an empty set of read-only parameters, for AbstractHttpMessage and similar usage patterns.
interface HttpParams (ro)
+- interface ModifiableHttpParams
class AbstractHttpParams (ro) implements HttpParams
+- class AbstractModifiableHttpParams implements ModifiableHttpParams
+ class BasicHttpParams
Within the framework the parameters are used read-only, so the HttpParams interface doesn't have to be replaced with the modifiable version.
> Consider read-only HttpParams
> -----------------------------
>
> Key: HTTPCORE-101
> URL: https://issues.apache.org/jira/browse/HTTPCORE-101
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore, HttpCore NIO
> Affects Versions: 4.0-alpha5
> Reporter: Roland Weber
> Assignee: Roland Weber
> Priority: Minor
> Fix For: 4.0-alpha6
>
>
> Consider turning HttpParams into a read-only interface, moving modifiers to an extension interface.
> Suggested by Daniel Müller on httpcomponents-dev.
> This will break the following style of updating existing parameters:
> xxx.getParams().setParameter("name", value);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org