Salut,
Ray Racine wrote:
> 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 ****!!
+1
>
> 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.
We have almost all objects needed to build such clients API right now
available. We just need to define the API and then start hooking the
proper class. Might have to refactor the http module for sure....
>
> Oh, btw I find the OSGi support a nice thing. Thanks.
Thanks. The idea here for the http async client is to re-use/re-factor
what we have on the server side. That's why I've openned:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=265
Thanks both of you for the feedback!
-- Jeanfrancois
>
> Keep up the good work.
>
> R.
>
>
> On Mon, Oct 27, 2008 at 10:59 AM, Kedar Mhaswade <Kedar.Mhaswade_at_sun.com
> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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
> <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>
>
>