Thank you very much.
That is input that I was looking for. I'll report back with status update.
Regards,
Hubert
On Thu, Apr 30, 2009 at 2:14 AM, Jeanfrancois Arcand <
Jeanfrancois.Arcand_at_sun.com> wrote:
> Salut
>
> Hubert Iwaniuk wrote:
>
>> Hi All,
>>
>> I've got first step on http client: Controller to connect to GWS and get
>> response.
>>
>> My plan is as follows:
>> - to be able to provide http client "Reqeust" object inseted of doing it
>> by hand (calling .write(...)).
>> - to parse response and wrap it in Request userfriendly object, that
>> would encapsulate all the headers cookies and other goodies.
>> - persistent client connections.
>> - multithreading.
>>
>
> +1
>
>
>> As principle I would like to reuse as much as possible of current code
>> base, don't like reinventing a wheel, it's provent that current code works.
>>
>> I would like to get some help of you guys on first step.
>>
>> I'm trying to reuse Grizzly/Reqeuest Grizzly/Response objects for client.
>> It seems like this objects are quite bound to internals of grizzly.
>> Question: should I try reusign them? That would mean refactoring so users
>> could easily create Reqeusts by themselfs.
>>
>
> I would think they should work as soon as you populate their associated
> object under the hood properly. What you really need to investigate is the
> use of ProcessorTask as generic http parser. Personally I do think you can
> probably re-use that object as soon as you have an InputStream/SocketChannel
> available. The DefaultProtocolFilter under the http module can probably be
> used to as-it-is, e.g it will drive the ProtocolTask execution.
>
> In that sense, all you will need to do is to write an Adapter that will
> gets invoked when the http response as been parsed. Inside this Adapter you
> will get a GrizzlyRequest/GrizlyResponse, except for the client case, the
> GrizzlyRequest is the remote server response. So you just need to wrap that
> object (or extends) into a ClientResponse. Same with GrizzlyResponse, which
> becomes the ClientRequest.
>
> Let's explore if the above proposal work...I would think it is not too
> complex to re-use the ReasFilter/DefaultProtocolFilter/GrizlyAdapter...the
> tricky part will be the ClientRequest/Response.
>
> So for your client code, you need to make sure that from inside your
> CallbackHandler, the onWrite implementation isn't invoking the ProtocolChain
> (e.g. ReadFilter, DefaultProtocolFilter). Only when onRead(...) gets
> invoked.
>
> Note that currently the DefaultProtocolFilter blocks, but we can make it
> non blocking by properly configuring a StreamAlgorithm (several non blocking
> are available already in Grizzly). But I would first start with a blocking
> approach.
>
> How does it sound?
>
>
> As I see it now Request is more of a view of parsed http reqeuest, ti
>> seems quite hard to create proper Request object by hand.
>> Also could some Response "serialization" be reused for sending of Reqeust,
>> so once we have Request object ready to reuse something that would take care
>> of putting it on a wire properly including taking care of possible
>> streams?
>>
>
> +1
>
>
>
>> I'll refactor code that I have so it makes more sense and commit stuff in
>> contrib so other can see what is happening with client and to help :-)
>>
>
> Keep the questions coming!
>
> A+
>
> -- Jeanfrancois
>
>
>
>> Thank you in advance,
>> Hubert.
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
>