Is the Disk Cache safe across multiple processes?

[yschimke]

OkHttp Cache is single instance/process, although you can reuse the same instance with multiple clients. What are the restrictions/guarantees for the new Coil disk cache in 2?

[colinrtwhite]

I believe it's the same in Coil 2.x (it's single instance/process). By default, we share a DiskCache instance between ImageLoaders to prevent multiple disk cache instances acting in the same directory. Internally, Coil's DiskLruCache is a slightly modified version of OkHttp's (also let me know if you want better credits added to that file - I only kept the existing file header).

[yschimke]

Not from me, it predates my time. I think reuse of this in any form is a good thing. Let us know if there are non trivial bug fixes or any efforts required for KMM.

cc @swankjesse

[swankjesse]

Yep, glad this could be helpful and I think it's useful to expose the File this way.

The only extra thing I'd consider for Coil is using SQLite instead of the journal file. It'd be a difficult migration, but once it's done you could keep more metadata (image dimensions? Full-size URL?). I'd switch OkHttp to SQLite but that is not available outside of Android.

[yschimke]

Given the problems with cache files on Android, this seems like an interesting idea on Android anyway. We can build against the Android APIs now. Although more complicated if it means APIs above that like Room, SQLDelight etc. Maybe a good thing to support as an optional module for OkHttp 5. Is there a way to do this cleanly via a Cache-like interfaces?

[colinrtwhite]

@swankjesse Great point - I don't think this would make it in for 2.0 stable, but we could always migrate existing journal files to SQLite in a subsequent minor version.

[yschimke]

Is there still enough commonality that we could write this and share it? OR a base class?

If we want to do this, we should probably look at how to backwards compatibly allow different Cache implementations, the current version is better allowing Okio FileSystem, but not flexible enough.

[swankjesse]

Good point. On Android we could probably just use SQLite instead of a journal and keep that as an implementation detail.