Re: What about optional components?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] - 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]
Re: What about optional components?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about optional components?
+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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about optional components?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Re: What about optional components?
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about optional components?
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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What about optional components?
- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What about optional components?
Oleg et al, I think this would be an excellent solution. Perhaps it could start out as a useful tools and tips page? We could provide the code to detect proxy settings in applets there as a start and am sure there's other stuff that could be added as well? Post 2.1 we could then expand this to provide support for development of these add-ons etc similar to how ant does. Adrian Sutton, Software Engineer Ephox Corporation www.ephox.com -Original Message- From: Oleg Kalnichevski [mailto:[EMAIL PROTECTED]] Sent: Thursday, 20 February 2003 2:08 AM To: Commons HttpClient Project Subject: 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
