Hi,
just wanted to sum up what we have.
1) HTTP client API may be based on Jersey client API [1]
2) Grizzly NIO (NIO.2) based implementation
3) Compliant with HTTP 1.1?
4) Support asynchronous execution based on Future and/or
CompletionHandler
5) Intermediate progress support (could be implemented via
CompletionHandler API).
6) Built-in support for "server-push" technologies (will it require
something extra?)
7) Multi-part post. Will be implemented as WebResource.post() [2]
8) Security (HTTPS) support
WBR,
Alexey.
[1]
https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0/api/jersey/com/sun/jersey/api/client/package-summary.html
[2]
https://jersey.dev.java.net/source/browse/*checkout*/jersey/tags/jersey-1.0/api/jersey/com/sun/jersey/api/client/WebResource.html
#post(com.sun.jersey.api.client.GenericType)
On Mar 2, 2009, at 18:57 , Pauls, Karl wrote:
> Hello again! I've done a bit of http client use so I have a few
> suggestions:
>
> * UrlConnection IS effectively deprecated (like Date) - I think
> everyone's on board here... if not:
> this is the reality of the Java library - old API's don't die,
> aren't deprecated, they just linger and are not improved
> There was no interest in adapting UrlConnection to NIO or NIO.2 at
> JavaOne '08, I asked
> Do not use UrlConnection as a fallback/excuse for prohibiting a
> feature
> but you don't have to implement absolutly everything, just provide
> empty protected methods which allow the user to implement these
> (Proxy, Cert handling, and such)
>
> * Jetty's Future-based interface is very nice for user-end code.
> There are some essential services that I feel client implementers
> may think are missing
> CompletionService support is absolutely essential
> single-in multiple-out (first responder wins input fight) for a
> shared Future without wasting resources (from Paul's assessment is
> this the Jersey inefficiency? wasted threads?)
> implementers will want non-blocking offer directly on the Future
> I've done some legwork in this direction and have generalized how
> Future.cancel() can callback to the IO API to free resources (yes
> that means the first user to cancel a shared future cancels all,
> like deleting from an Iterator affects the list)
>
> * intermediate progress support for extreme user feedback
> protected void connectionProgress(String property, int value) {
> }
> this will let Swing programmers write their own
> AsynchUrlConnectionSwingWorker
>
> * for get(Class<T> c) I was going to suggest some specific required
> implementations (javax.transform.Source) but maybe just provide an
> overridable factory
>
> -karl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>