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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
