On 09/08/12 06:10, Sean Chou wrote:
Hi Chris,
That's exactly my concern. I agree this provides best flexibility
and content convenient methods are not proper in this API. So, is there
going to have content specific convenient APIs like java.nio.file.Files
? Although it is a wrapper, it may be useful and intuitive, and easy to
use for those who just want to open a webpage but don't want to know
request and response. And as well doesn't break modularization. Thanks.
I think it is certainly worth some consideration, but exactly where it
would reside and how it could be specified without "breaking" modularity
is a bit of a conundrum. Most of the types that would be useful to have
in such a wrapper/convenience/utility API will come from modules that
are not from the same module as the httpclient will most likely be
targeted to. So any API will have cross module dependencies ( not
necessarily a problem ), just need to think through the implications.
-Chris
On Wed, Aug 8, 2012 at 5:52 PM, Chris Hegarty <chris.hega...@oracle.com
<mailto:chris.hega...@oracle.com>> wrote:
On 08/08/2012 07:25, Sean Chou wrote:
Is it possible to have methods like
public abstract HTMLDocument getResponse(String request) in class
HttpClient ?
Hi Sean,
I think what you are suggesting is content specific convenience
methods, something akin to URLConnection.getContent(), right? In my
experience, this type of interface can be a little problematic and
not all that widely used.
I'm personally not in favor of such convenience methods. I can see
their potential value, but this would appear to be a low level API
and I don't think it should favor one specific content type over
another.
From my reading of the API it exposes various methods to access the
response body. It is quite easy to wrap one of these in a content
specific parser. For example, for xml you could do
XMLInputFactory xif = ...;
xif.createStreamReader(client.__getResponse(request).__getBodyAsInputStream());
OR
SAXParserFactory spf = ...;
spf.newSAXParser().parse(__client.getResponse(request).__getBodyAsInputStream(),
handler);
I think this gives the best flexibility without favoring one content
type parser, or one programming model, over another.
Does this make sense? Have I missed the point of your proposal?
Maybe others have a different view...
-Chris.
On Wed, Aug 8, 2012 at 7:09 AM, Michael McMahon
<michael.x.mcma...@oracle.com
<mailto:michael.x.mcma...@oracle.com>
<mailto:michael.x.mcmahon@__oracle.com
<mailto:michael.x.mcma...@oracle.com>>> wrote:
Hi,
A new revision of the Http client API planned for jdk 8 can
be viewed
at the following link
http://cr.openjdk.java.net/~____michaelm/httpclient/v0.3/
<http://cr.openjdk.java.net/~__michaelm/httpclient/v0.3/>
<http://cr.openjdk.java.net/~__michaelm/httpclient/v0.3/
<http://cr.openjdk.java.net/~michaelm/httpclient/v0.3/>>
We would like to review the api on this mailing list.
So, all comments are welcome.
Thanks
Michael McMahon.
--
Best Regards,
Sean Chou
--
Best Regards,
Sean Chou