Salut,
Richard Corsale wrote:
> Hi Hubert,
>
> I've spent so much of professional time developing web crawlers in Java
> that I don't even know where to begin :). I would like to propose an
> alternative, one that I think would be superior overall... Why not dig
> in and create an alternative method of connection to a GWS.
I think both exercise can be executed in parallel.
I personally
> think that Comet is pushing the boundaries of HTTP as it is. I also
> think that future releases of JavaScript will enable UDP connections to
> be establised from the browser... lets get out in font of this and
> create an NIO blocking UDP gateway as a front end for Grizzly!!
So you want http over UDP? Quite easy to do IMO with the current 1.9.x
(I did the same kind of implementation for Sailfin, e.g. SIP over UDP or
TCP.
I've
> been thinging about this ALOT, as the core of the project that I'm
> devoting 100% of my time to requires interserver comminication... This
> would allow for easy java client development. Not only that, but lets
> think about this.. if we had an underlying UDP gateway, we could write
> any protocol wrapper we wanted ontop of that gateway to support any
> protocol spec with ease.
Why not stating a new thread discussion? Just give more details about
what you have in mind.
Thanks!
-- Jeanfrancois
P.S You don't any idea good idea about a logo for my other project
(atmosphere.dev.java.net) by any chance :-) The Grizzly's one will kill
the competition on a t-shirt next JavaOne :-)
>
> -- My two cents
> Richard
>
> ------------------------------------------------------------------------
> *From:* Hubert Iwaniuk <neotyk_at_kungfoo.pl>
> *To:* dev_at_grizzly.dev.java.net
> *Sent:* Wednesday, April 29, 2009 11:12:26 AM
> *Subject:* Http Client discussion part1
>
> 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.
>
> 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.
> 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?
>
> 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 :-)
>
> Thank you in advance,
> Hubert.
>