Hi Julien,
There are 8 issues in trunk about the fetcher - some of them unrelated to > the Fetcher (NUTCH-827 <https://issues.apache.org/jira/browse/NUTCH-827>/ > Nutch-1193) with most of the others being improvements ( > NUTCH-828 <https://issues.apache.org/jira/browse/NUTCH-828> / > NUTCH-1079<https://issues.apache.org/jira/browse/NUTCH-1079>) > with possibly just a very few being real issues. This puts the whole discussion into much better context, thanks for pointing this out. Maybe I should have made it more clear, that I only filtered the fetcher issues on our Jira and I was simply modelling my discussion around that. You are completely correct though, it would be different if the fetcher was in a similar state to protocol-httpclient... which it is obviously not. > I am also concerned about getting too radical changes to such a core part > of the framework, especially when more pressing issues could be looked > after instead. +1 > Having said that if someone can come up with an interesting proposal for > improving the Fetcher that would be very good, I would simply suggest that > we then have a separate implementation for that. > +1 > > > Ok with this in mind then, is there some guidance we can communicate to Eddie? He has specifically mentioned that he shares similar opinions wrt the fetcher being a core part of Nutch, radical changes etc, and I also share this point of view. He has also added that he doesn't want to spend the time changing material which we may or may not merge with trunk, this also makes perfect sense. Additionally Ken's comments emphasise that this has been somewhat attempted in the past and that lessons have been learned and the implementation we have cuts the mustard as is. Maybe we could nudge Eddie in the right direction, which would benefit both himself and the project over the next while, I think this was the most important point I was trying to emphasise, however looking over my original comment this was maybe not how it was written. Thanks Lewis
