[ 
https://issues.apache.org/jira/browse/HTTPCLIENT-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920216#action_12920216
 ] 

Jonathan Moore commented on HTTPCLIENT-1005:
--------------------------------------------

Oleg,

I'm also somewhat torn. I believe that the current set of functionality is a 
"minimum viable product" (probably more than minimum) and would like to get a 
GA release including it out as soon as possible. On the other hand, at least 
some of the upcoming anticipated changes (particularly, request collapsing and 
asynchronous validation) are likely to involve structural changes; or at least 
they are different enough that there is a nontrivial risk that they would break 
the current binary API. At the same time, while I do think we'll get to those 
new features, it may well take a couple of months for us, and I'm not really 
crazy about holding up the GA release for those.

As this is the first GA release of the caching module, I'd say we actually 
don't really know how people are going to want to extend it (or even if they 
will want to extend it at all). If we want to strive for binary 
backwards-compatibility, then I'd say we should conservatively err on the side 
of closing down the interface. We can always expose more of the interface in a 
later release if folks want it, and I'd rather be in that position than trying 
to put toothpaste back into the tube (possibly compromising the design of the 
code in order to retain backwards compatibility).

Jon

> API surface of caching module can be reduced
> --------------------------------------------
>
>                 Key: HTTPCLIENT-1005
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1005
>             Project: HttpComponents HttpClient
>          Issue Type: Improvement
>          Components: Cache
>    Affects Versions: 4.1 Alpha2
>            Reporter: Jonathan Moore
>         Attachments: smaller-api.patch
>
>
> While the caching module can currently be considered functional and useful 
> for folks as-is, there are several near-term enhancements planned that could 
> change the exposed binary API of the caching module (although it is not yet 
> clear whether they would or not). In an effort to allow the 4.1 GA release to 
> go forward while hedging bets against future development, we should consider 
> drastically reducing the exposed binary API of the caching module, and not 
> exposing extension points until someone explicitly asks for them.

-- 
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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to