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 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!! 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.
-- 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.