Some thoughts.
For me, command line is not as important. I'll just use curl or simple
Python script for quick and dirty command line tests anyway.
Concurrency, and request coordination are key.
Use Case
------------
Use HTTP for default protocol for series of peer applications. (Not ol'
fashioned WebServing)
Typical need:
- application receives HTTP request to PUT/GET a resource from client.
- receiving application delegates/forwards HTTP request to peer system(s)
as a series of spawned _parallel_ requests.
- response to client request based on peer responses.
Needs
- Application acts as a Peer, both sending and receiving HTTP based
requests ie both a client and a server.
- Should be able to forward/proxy HTTP efficiently.
- Understand detailed HTTP 1.1. caching.
- Deal with data payloads ie. lots of PUT/POST as well as GETS.
- Need efficient use of buffers and recycling to receive and/or forward
stream data payload in 10,100, 100 K range on processing PUT/POSTs.
- Support for efficient spawning/coordinating parallel HTTP client
requests.
- e.g, application spawns in parallel N HTTP Gets/Puts... joins/waits on
completion of M client requests. (M < N)
- !!**** think java.lang.concurrency Executors, Futures, and and
CompletionService but high level HTTP aware versions ****!!
The main thrust here is
- HTTP as THE protocol for all communications, Web, DataCenter, Distributed
Apps.
- Parallel/Concurrency of lots and lots of HTTP send/gets.
Synchronizing/coordinating multiple parallel requests with timeouts.
(Synch/Join/Pi calculus like)
- HTTP 1.1 proxying and caching.
- Efficient handling of various sized data payloads. As much Putting and
Posting with data as Getting of data.
There you go, some thoughts from my end which I realize is very HTTP
centric.
Oh, btw I find the OSGi support a nice thing. Thanks.
Keep up the good work.
R.
On Mon, Oct 27, 2008 at 10:59 AM, Kedar Mhaswade <Kedar.Mhaswade_at_sun.com>wrote:
> Yes, this is something on my mind. I need to find time to sit down and
> do this at once. Will update the list soon.
>
> I have done some amount of research on this topic and am now in a position
> to write down something about it (so that it forms a semi-formal spec for
> the functionality).
>
> I need to understand how community thinks about this entire http client
> thingie :) before proceeding:
>
> - What is the current inclination of this community about *existing* http
> client programs? (examples: cURL, wget)
>
> - A command line is necessary (something like grzget) but an API is more
> important, correct?
>
> - Suppose I were to do a command line, I'd like to stick to an existing
> and robust command line interface (e.g. cURL) so that users don't have
> to learn anything new.
>
> - Number of protocols -- this is an on-going task because we will support
> a number of protocols as we make progress. But to begin with, the first
> release of this library/CLI should support HTTP/HTTPS/FTP with necessary
> support via proxies and various authentication policies.
>
> I'd utilize community response here and commit to a spec in a few days :)
>
> Regards,
> Kedar
>
> Ray Racine wrote:
>
>> +1 Important for me as well.
>>
>> R.
>>
>> On Mon, Oct 27, 2008 at 9:32 AM, Jeanfrancois Arcand <
>> Jeanfrancois.Arcand_at_sun.com <mailto:Jeanfrancois.Arcand_at_sun.com>> wrote:
>>
>> Salut,
>>
>>
>> Bill Robertson wrote:
>>
>> Any progress?
>>
>>
>> Jeanfrancois Arcand-2 wrote:
>>
>> we don't yet support http client:
>> https://grizzly.dev.java.net/issues/show_bug.cgi?id=265
>>
>>
>> Yes. Kedar (on that list) told me he was interested to work on this.
>> I can't say when we will have it, but at least we have some interest
>> :-) As usual, patches/contributions are welcome!
>>
>> A+
>>
>> -- Jeanfrancois
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> <mailto:users-unsubscribe_at_grizzly.dev.java.net>
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>> <mailto:users-help_at_grizzly.dev.java.net>
>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>