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

Reply via email to