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.