Salut,
Oleksiy Stashok wrote:
> 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?
It MUST :-)
> 4) Support asynchronous execution based on Future and/or CompletionHandler
Both like AIO IMO :-) So support blocking and non blocking I/O operation.
> 5) Intermediate progress support (could be implemented via
> CompletionHandler API).
> 6) Built-in support for "server-push" technologies (will it require
> something extra?)
Hum...at least not for first version?
> 7) Multi-part post. Will be implemented as WebResource.post() [2]
> 8) Security (HTTPS) support
>
+1
-- Jeanfrancois
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>