You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Oleg Kalnichevski <o....@dplanet.ch> on 2003/02/19 17:07:40 UTC
What about optional components?
Adrian (and all)
I agree that with you about keeping HttpClient JVM independent and
reasonably generic. Clearly proxy detection should be kept outside
HttpClient package IMHO.
But you know what? Maybe HttpClient have matured well enough so that we
have reached the point where we should start (thinking about) collecting
contributions or optional packages (pretty much in the same manner Ant
is structured into core & optional packages) that are not officially an
integral part of HttpClient, nevertheless useful enough to be made
available to the public? Would it be worthwhile having a greater ecology
around HttpClient? Any thoughts?
Cheers
Oleg
On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
> > Could we provide the code below in some Utility function?
> > I guess this is convenient for people making Applets - although Applets
> > are generally a bad idea :-)
>
> Sadly, this code will not work on OS X or most non-sun JREs. The location
> of proxy information is very much platform, JVM and plugin dependant. I'd
> say it would be a bad idea to include this in HttpClient, but including it
> as an initial starting point in the docs may be worth while.
>
> I guess it depends what the scope of HttpClient is, but I would have thought
> that the proxy configuration should be something that's passed into
> HttpClient rather than something it tries to figure out. A separate project
> which detects proxy settings in applets on various platforms, has the
> ability to parse the auto-configuration pages for proxies etc, but it really
> is a big can of worms that I don't think HttpClient needs (particularly
> coming up to a release).
>
> Adrian Sutton.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: What about optional components?
Posted by Jeffrey Dever <js...@sympatico.ca>.
Thats a fine idea. I'm all for it.
+1
Oleg Kalnichevski wrote:
>Jandalf
>
>I see your point. However, there's a concern which I would like to be
>taken into consideration. It might take quite a while before we make it
>past 2.2 release. A lot of useful code may simply be lost during that
>time. There has already been a few cases when the contribution did not
>merit inclusion into the main HttpClient source tree but might still be
>considered useful for some users.
>
>I was thinking about something very simple for a start: just another
>folder under <root>/src folder. Something like <root>/src/contrib, which
>would contain a package named org.apache.commons.httpclient.contrib or
>something similar. This package would not be officially maintained. It
>would not be included into neither BIN nor SRC distribution, however, it
>would still be available for retrieval from CVS. In this way we might
>benefit from receiving feedback on what kind of optional features are
>considered popular or useful by the HttpClient's user base
>
>In my opinion, this approach would not unnecessarily broaden the scope
>of the project, but might still help in fostering a greater ecology
>around HttpClient
>
>Cheers
>
>Oleg
>
>
>
>On Wed, 2003-02-19 at 18:02, Jeffrey Dever wrote:
>
>
>>Interesting. It sounds like we are talking about a 2.2 (or 3.0 feature)
>>but it is possible. One conern I have is that HttpClient is a very
>>large project as part of commons, and if we do increase its scope then
>>we may also be considering moving to be a top level Jakarta project.
>>
>>I would not suggest this now, but perhaps this might be in store for 3.0.
>>
>>Jandlaf.
>>
>>
>>Michael Becke wrote:
>>
>>
>>
>>>Sounds like a fine idea Oleg.
>>>
>>>I agree we should probably look to other jakarta project for how they
>>>handle this kind of thing. As you said Ant does this and I believe
>>>Log4j does as well.
>>>
>>>Mike
>>>
>>>Oleg Kalnichevski wrote:
>>>
>>>
>>>
>>>>Adrian (and all)
>>>>
>>>>I agree that with you about keeping HttpClient JVM independent and
>>>>reasonably generic. Clearly proxy detection should be kept outside
>>>>HttpClient package IMHO.
>>>>
>>>>But you know what? Maybe HttpClient have matured well enough so that we
>>>>have reached the point where we should start (thinking about) collecting
>>>>contributions or optional packages (pretty much in the same manner Ant
>>>>is structured into core & optional packages) that are not officially an
>>>>integral part of HttpClient, nevertheless useful enough to be made
>>>>available to the public? Would it be worthwhile having a greater ecology
>>>>around HttpClient? Any thoughts?
>>>>
>>>>Cheers
>>>>
>>>>Oleg
>>>>
>>>>On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
>>>>
>>>>
>>>>
>>>>>>Could we provide the code below in some Utility function?
>>>>>>I guess this is convenient for people making Applets - although
>>>>>>Applets
>>>>>>are generally a bad idea :-)
>>>>>>
>>>>>>
>>>>>Sadly, this code will not work on OS X or most non-sun JREs. The
>>>>>location
>>>>>of proxy information is very much platform, JVM and plugin
>>>>>dependant. I'd
>>>>>say it would be a bad idea to include this in HttpClient, but
>>>>>including it
>>>>>as an initial starting point in the docs may be worth while.
>>>>>
>>>>>I guess it depends what the scope of HttpClient is, but I would have
>>>>>thought
>>>>>that the proxy configuration should be something that's passed into
>>>>>HttpClient rather than something it tries to figure out. A separate
>>>>>project
>>>>>which detects proxy settings in applets on various platforms, has the
>>>>>ability to parse the auto-configuration pages for proxies etc, but
>>>>>it really
>>>>>is a big can of worms that I don't think HttpClient needs (particularly
>>>>>coming up to a release).
>>>>>
>>>>>Adrian Sutton.
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail:
>>>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail:
>>>>>commons-httpclient-dev-help@jakarta.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail:
>>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail:
>>>>commons-httpclient-dev-help@jakarta.apache.org
>>>>
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail:
>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail:
>>>commons-httpclient-dev-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
>
>
>
Re: What about optional components?
Posted by Michael Becke <be...@u.washington.edu>.
Sounds like a good plan. I was thinking we might want to include the
contrib code in the source distribution. It would be more convenient
for users and I think it would help to promote code contribution.
Mike
+1
Oleg Kalnichevski wrote:
> Jandalf
>
> I see your point. However, there's a concern which I would like to be
> taken into consideration. It might take quite a while before we make it
> past 2.2 release. A lot of useful code may simply be lost during that
> time. There has already been a few cases when the contribution did not
> merit inclusion into the main HttpClient source tree but might still be
> considered useful for some users.
>
> I was thinking about something very simple for a start: just another
> folder under <root>/src folder. Something like <root>/src/contrib, which
> would contain a package named org.apache.commons.httpclient.contrib or
> something similar. This package would not be officially maintained. It
> would not be included into neither BIN nor SRC distribution, however, it
> would still be available for retrieval from CVS. In this way we might
> benefit from receiving feedback on what kind of optional features are
> considered popular or useful by the HttpClient's user base
>
> In my opinion, this approach would not unnecessarily broaden the scope
> of the project, but might still help in fostering a greater ecology
> around HttpClient
>
> Cheers
>
> Oleg
>
>
>
> On Wed, 2003-02-19 at 18:02, Jeffrey Dever wrote:
>
>>Interesting. It sounds like we are talking about a 2.2 (or 3.0 feature)
>>but it is possible. One conern I have is that HttpClient is a very
>>large project as part of commons, and if we do increase its scope then
>>we may also be considering moving to be a top level Jakarta project.
>>
>>I would not suggest this now, but perhaps this might be in store for 3.0.
>>
>>Jandlaf.
>>
>>
>>Michael Becke wrote:
>>
>>
>>>Sounds like a fine idea Oleg.
>>>
>>>I agree we should probably look to other jakarta project for how they
>>>handle this kind of thing. As you said Ant does this and I believe
>>>Log4j does as well.
>>>
>>>Mike
>>>
>>>Oleg Kalnichevski wrote:
>>>
>>>
>>>>Adrian (and all)
>>>>
>>>>I agree that with you about keeping HttpClient JVM independent and
>>>>reasonably generic. Clearly proxy detection should be kept outside
>>>>HttpClient package IMHO.
>>>>
>>>>But you know what? Maybe HttpClient have matured well enough so that we
>>>>have reached the point where we should start (thinking about) collecting
>>>>contributions or optional packages (pretty much in the same manner Ant
>>>>is structured into core & optional packages) that are not officially an
>>>>integral part of HttpClient, nevertheless useful enough to be made
>>>>available to the public? Would it be worthwhile having a greater ecology
>>>>around HttpClient? Any thoughts?
>>>>
>>>>Cheers
>>>>
>>>>Oleg
>>>>
>>>>On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
>>>>
>>>>
>>>>>>Could we provide the code below in some Utility function?
>>>>>>I guess this is convenient for people making Applets - although
>>>>>>Applets
>>>>>>are generally a bad idea :-)
>>>>>
>>>>>
>>>>>Sadly, this code will not work on OS X or most non-sun JREs. The
>>>>>location
>>>>>of proxy information is very much platform, JVM and plugin
>>>>>dependant. I'd
>>>>>say it would be a bad idea to include this in HttpClient, but
>>>>>including it
>>>>>as an initial starting point in the docs may be worth while.
>>>>>
>>>>>I guess it depends what the scope of HttpClient is, but I would have
>>>>>thought
>>>>>that the proxy configuration should be something that's passed into
>>>>>HttpClient rather than something it tries to figure out. A separate
>>>>>project
>>>>>which detects proxy settings in applets on various platforms, has the
>>>>>ability to parse the auto-configuration pages for proxies etc, but
>>>>>it really
>>>>>is a big can of worms that I don't think HttpClient needs (particularly
>>>>>coming up to a release).
>>>>>
>>>>>Adrian Sutton.
>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail:
>>>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>>For additional commands, e-mail:
>>>>>commons-httpclient-dev-help@jakarta.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail:
>>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>>For additional commands, e-mail:
>>>>commons-httpclient-dev-help@jakarta.apache.org
>>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail:
>>>commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail:
>>>commons-httpclient-dev-help@jakarta.apache.org
>>>
>>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: What about optional components?
Posted by Ortwin Glück <or...@nose.ch>.
+1
Very much appreciated.
Oleg Kalnichevski wrote:
> Something like <root>/src/contrib, which
> would contain a package named org.apache.commons.httpclient.contrib or
> something similar. This package would not be officially maintained. It
> would not be included into neither BIN nor SRC distribution, however, it
> would still be available for retrieval from CVS.
> fostering a greater ecology
> around HttpClient
Re: What about optional components?
Posted by Oleg Kalnichevski <o....@dplanet.ch>.
Jandalf
I see your point. However, there's a concern which I would like to be
taken into consideration. It might take quite a while before we make it
past 2.2 release. A lot of useful code may simply be lost during that
time. There has already been a few cases when the contribution did not
merit inclusion into the main HttpClient source tree but might still be
considered useful for some users.
I was thinking about something very simple for a start: just another
folder under <root>/src folder. Something like <root>/src/contrib, which
would contain a package named org.apache.commons.httpclient.contrib or
something similar. This package would not be officially maintained. It
would not be included into neither BIN nor SRC distribution, however, it
would still be available for retrieval from CVS. In this way we might
benefit from receiving feedback on what kind of optional features are
considered popular or useful by the HttpClient's user base
In my opinion, this approach would not unnecessarily broaden the scope
of the project, but might still help in fostering a greater ecology
around HttpClient
Cheers
Oleg
On Wed, 2003-02-19 at 18:02, Jeffrey Dever wrote:
> Interesting. It sounds like we are talking about a 2.2 (or 3.0 feature)
> but it is possible. One conern I have is that HttpClient is a very
> large project as part of commons, and if we do increase its scope then
> we may also be considering moving to be a top level Jakarta project.
>
> I would not suggest this now, but perhaps this might be in store for 3.0.
>
> Jandlaf.
>
>
> Michael Becke wrote:
>
> > Sounds like a fine idea Oleg.
> >
> > I agree we should probably look to other jakarta project for how they
> > handle this kind of thing. As you said Ant does this and I believe
> > Log4j does as well.
> >
> > Mike
> >
> > Oleg Kalnichevski wrote:
> >
> >> Adrian (and all)
> >>
> >> I agree that with you about keeping HttpClient JVM independent and
> >> reasonably generic. Clearly proxy detection should be kept outside
> >> HttpClient package IMHO.
> >>
> >> But you know what? Maybe HttpClient have matured well enough so that we
> >> have reached the point where we should start (thinking about) collecting
> >> contributions or optional packages (pretty much in the same manner Ant
> >> is structured into core & optional packages) that are not officially an
> >> integral part of HttpClient, nevertheless useful enough to be made
> >> available to the public? Would it be worthwhile having a greater ecology
> >> around HttpClient? Any thoughts?
> >>
> >> Cheers
> >>
> >> Oleg
> >>
> >> On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
> >>
> >>>> Could we provide the code below in some Utility function?
> >>>> I guess this is convenient for people making Applets - although
> >>>> Applets
> >>>> are generally a bad idea :-)
> >>>
> >>>
> >>> Sadly, this code will not work on OS X or most non-sun JREs. The
> >>> location
> >>> of proxy information is very much platform, JVM and plugin
> >>> dependant. I'd
> >>> say it would be a bad idea to include this in HttpClient, but
> >>> including it
> >>> as an initial starting point in the docs may be worth while.
> >>>
> >>> I guess it depends what the scope of HttpClient is, but I would have
> >>> thought
> >>> that the proxy configuration should be something that's passed into
> >>> HttpClient rather than something it tries to figure out. A separate
> >>> project
> >>> which detects proxy settings in applets on various platforms, has the
> >>> ability to parse the auto-configuration pages for proxies etc, but
> >>> it really
> >>> is a big can of worms that I don't think HttpClient needs (particularly
> >>> coming up to a release).
> >>>
> >>> Adrian Sutton.
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail:
> >>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >>> For additional commands, e-mail:
> >>> commons-httpclient-dev-help@jakarta.apache.org
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail:
> >> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail:
> >> commons-httpclient-dev-help@jakarta.apache.org
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > commons-httpclient-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> > commons-httpclient-dev-help@jakarta.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: What about optional components?
Posted by Jeffrey Dever <js...@sympatico.ca>.
Interesting. It sounds like we are talking about a 2.2 (or 3.0 feature)
but it is possible. One conern I have is that HttpClient is a very
large project as part of commons, and if we do increase its scope then
we may also be considering moving to be a top level Jakarta project.
I would not suggest this now, but perhaps this might be in store for 3.0.
Jandlaf.
Michael Becke wrote:
> Sounds like a fine idea Oleg.
>
> I agree we should probably look to other jakarta project for how they
> handle this kind of thing. As you said Ant does this and I believe
> Log4j does as well.
>
> Mike
>
> Oleg Kalnichevski wrote:
>
>> Adrian (and all)
>>
>> I agree that with you about keeping HttpClient JVM independent and
>> reasonably generic. Clearly proxy detection should be kept outside
>> HttpClient package IMHO.
>>
>> But you know what? Maybe HttpClient have matured well enough so that we
>> have reached the point where we should start (thinking about) collecting
>> contributions or optional packages (pretty much in the same manner Ant
>> is structured into core & optional packages) that are not officially an
>> integral part of HttpClient, nevertheless useful enough to be made
>> available to the public? Would it be worthwhile having a greater ecology
>> around HttpClient? Any thoughts?
>>
>> Cheers
>>
>> Oleg
>>
>> On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
>>
>>>> Could we provide the code below in some Utility function?
>>>> I guess this is convenient for people making Applets - although
>>>> Applets
>>>> are generally a bad idea :-)
>>>
>>>
>>> Sadly, this code will not work on OS X or most non-sun JREs. The
>>> location
>>> of proxy information is very much platform, JVM and plugin
>>> dependant. I'd
>>> say it would be a bad idea to include this in HttpClient, but
>>> including it
>>> as an initial starting point in the docs may be worth while.
>>>
>>> I guess it depends what the scope of HttpClient is, but I would have
>>> thought
>>> that the proxy configuration should be something that's passed into
>>> HttpClient rather than something it tries to figure out. A separate
>>> project
>>> which detects proxy settings in applets on various platforms, has the
>>> ability to parse the auto-configuration pages for proxies etc, but
>>> it really
>>> is a big can of worms that I don't think HttpClient needs (particularly
>>> coming up to a release).
>>>
>>> Adrian Sutton.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> commons-httpclient-dev-help@jakarta.apache.org
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> commons-httpclient-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> commons-httpclient-dev-help@jakarta.apache.org
>
>
Re: What about optional components?
Posted by Michael Becke <be...@u.washington.edu>.
Sounds like a fine idea Oleg.
I agree we should probably look to other jakarta project for how they
handle this kind of thing. As you said Ant does this and I believe
Log4j does as well.
Mike
Oleg Kalnichevski wrote:
> Adrian (and all)
>
> I agree that with you about keeping HttpClient JVM independent and
> reasonably generic. Clearly proxy detection should be kept outside
> HttpClient package IMHO.
>
> But you know what? Maybe HttpClient have matured well enough so that we
> have reached the point where we should start (thinking about) collecting
> contributions or optional packages (pretty much in the same manner Ant
> is structured into core & optional packages) that are not officially an
> integral part of HttpClient, nevertheless useful enough to be made
> available to the public? Would it be worthwhile having a greater ecology
> around HttpClient? Any thoughts?
>
> Cheers
>
> Oleg
>
> On Wed, 2003-02-19 at 13:23, Adrian Sutton wrote:
>
>>>Could we provide the code below in some Utility function?
>>>I guess this is convenient for people making Applets - although Applets
>>>are generally a bad idea :-)
>>
>>Sadly, this code will not work on OS X or most non-sun JREs. The location
>>of proxy information is very much platform, JVM and plugin dependant. I'd
>>say it would be a bad idea to include this in HttpClient, but including it
>>as an initial starting point in the docs may be worth while.
>>
>>I guess it depends what the scope of HttpClient is, but I would have thought
>>that the proxy configuration should be something that's passed into
>>HttpClient rather than something it tries to figure out. A separate project
>>which detects proxy settings in applets on various platforms, has the
>>ability to parse the auto-configuration pages for proxies etc, but it really
>>is a big can of worms that I don't think HttpClient needs (particularly
>>coming up to a release).
>>
>>Adrian Sutton.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org
>
Re: What about optional components?
Posted by Ortwin Glück <or...@nose.ch>.
Max Voelkel wrote:
> - a Cache (mentioned a while ago on the list)
> - Proxy-Detection
okay
> - Some kind of "User-Agent" on top of HttpClient which:
> - handles Framesets (return urls of subframes)
> - possibly parses FORM-Tags
> - eventually handles JavaScript-Code and
> return the complete page (with document.write()-statements
> executed).
> - many more dreams here ...
This has *nothing* to do with HTTP (the focus of HttpClient) at all -
that is only HTML. HTTP is much more than transporting HTML!
HTML Parsers are already available for Java. No need for us to build one
into HttpClient. If anything then a HTTP Parses should go as a new
project under Commons or even Jakarta.
Odi
Re: What about optional components?
Posted by Jeffrey Dever <js...@sympatico.ca>.
> - a Cache (mentioned a while ago on the list)
>
A possibility, but likely more re-usable as a seperate project (there is
currently the beginnings of a cache in the sandbox, but appears idle)
> - Proxy-Detection
>
Another possibility
> - Some kind of "User-Agent" on top of HttpClient which:
> - handles Framesets (return urls of subframes)
> - possibly parses FORM-Tags
> - eventually handles JavaScript-Code and
> return the complete page (with document.write()-statements
> executed).
> - many more dreams here ...
>
>
This is definately outside the scope of httpclient. Remember that
HttpClient is HTTP (which is complex enough). HTML parsing and handling
would be a seperate project.
> I guess the generic User-Agent-part might become the next bigger
> project that leverages HttpClients functionality. Although it will
> need a lot of discussion to be generic & usefull enough for many
> people.
>
>
Cool idea. Think through the functionality that is required, and divide
into packages.
1) http connectivity
2) cache
3) html parsing
4) javascript parsing
Re: What about optional components?
Posted by Max Voelkel <ma...@xam.de>.
Hi Oleg and all,
I am using HttpClient for my diploma thesis and read this list for
two months now. I guess, there is really the demand for more optional
components around HttpClient, like:
- a Cache (mentioned a while ago on the list)
- Proxy-Detection
- Some kind of "User-Agent" on top of HttpClient which:
- handles Framesets (return urls of subframes)
- possibly parses FORM-Tags
- eventually handles JavaScript-Code and
return the complete page (with document.write()-statements
executed).
- many more dreams here ...
I guess the generic User-Agent-part might become the next bigger
project that leverages HttpClients functionality. Although it will
need a lot of discussion to be generic & usefull enough for many
people.
Max