PSA: Isolating core/fetch/ from the rest of core/

[Nate Chapin]

Greetings, blink-dev!

I've started work on https://crbug.com/458222, which seeks to ensure that the core/fetch/ directory doesn't depend on anything else in core/.  I hope this will be a step toward a more modular codebase with fewer circular dependencies. Also, core/fetch/ has historically been very minimally tested, and having a clean embedding interface should enable more precise and thorough testing.

If you are making changes in the fetch directory and want to make your code fit the new model, feel free to add me to your reviews.

Thanks,

~Nate

[Chris Harrelson]

Hi Nate,

Is this going to have a lot of impact on internal class APIs outside or inside of fetch?

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Nate Chapin]

The biggest impact it will have is that core/fetch/FetchContext.h interface and it's implementation in core/loader/FrameFetchContext.{h,cpp} will get a bit bigger, will core/fetch/ResourceFetcher.{h,cpp} get smaller.

I've already done a bit of cleanup in core/css and core/xml so that they get access to a Document pointer directly, rather than using ResourceFetcher::document().  I think that's the main API change, at least in terms of how the rest of core/ perceives core/fetch/.

Some classes may also be moved around, particularly between core/fetch/ and core/loader. These directories were historically one very broad directory, and the division we created was incomplete.  I'm trying to ensure core/loader/ is primarily navigation concepts and core/fetch/ is primarily generic resource loading concepts.

~Nate

[Chris Harrelson]

Ok. As long as it isn't a significant increase in complexity or awkwardness of interfaces, sounds fine. Was just checking whether that might be the case.

Thanks,

Chris