[Webkit-unassigned] [Bug 244058] [GLib] New API should use UnifiedOriginStorageLevel::Basic or UnifiedOriginStorageLevel::Standard

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=244058

--- Comment #3 from Sihui Liu <sihui_liu at apple.com> ---
(In reply to Michael Catanzaro from comment #2)
> I quickly skimmed through that commit.
> 
>  * Old WPE/GTK API has to keep using UnifiedOriginStorageLevel::None to
> support use of custom directories for different data types.
>  * New WPE/GTK API no longer allows setting custom directories for every
> data type, and only allows configuring the base data and base cache
> directories. So it should use at least UnifiedOriginStorageLevel::Basic.
> This should partition everything except cache?

Technically UnifiedOriginStorageLevel only indicates whether to the "General" directory for data types.
In our previous implementation, the directory structure looks like:
- WebsiteData/
  - CacheStorage
    - [Hashed Partitioned Origin]/
      - [Origin File]
      - [Record]/

Each type has its own directory, and origin file if the the origin directory name is hashed.
We later introduced a General directory, and the disk layout becomes:
- WebsiteData/
  - [General]
    - [Hashed Partitioned Origin]
      - [Origin File]
      - CacheStorage
        - [Record]
      - IndexedDB
      - LocalStorage
With new layout, we could eliminate unnecessary origin files and directories (good for backup). And it will be easier to apply same policy to all types (e.g. when a new type is added, we can just add another [Type] directory under partitioned origin directory without considering partitioning), and perform storage management (quote computation, data deletion, etc).

The new layout involves data migration (from custom directory to new directory) and some other work (refactoring, new architecture, testing, etc), so we are doing this type by type. We might not use the general directory for all types in the end, since some types use one single file for all origins for performance, and some types have different partition strategy, e.g. cookies.

Basically UnifiedOriginStorageLevel indicates the stage we are right now:
UnifiedOriginStorageLevel::None - don't use general directory for existing types
UnifiedOriginStorageLevel::Basic - use it for IndexedDB, LocalStorage
UnifiedOriginStorageLevel::Standard - use it for IndexedDB, LocalStorage, and CacheStorage
We are working towards UnifiedOriginStorageLevel::Standard now.
(Note FileSystem is a new type added after General directory is introduced, so it will be under this directory regardless of the level).

>  * We certainly want to partition cache data too. Is that the difference
> between UnifiedOriginStorageLevel::Basic vs.
> UnifiedOriginStorageLevel::Standard? Need to look closer. Apple is now
> putting cache under their origin directory, commingling cache and data. This
> would not be desirable for us because we should maintain clear separation
> between cache and data. I think we want one origin storage directory for
> cache and one for data.

If an existing type is partitioned now, it will be partitioned and UnifiedOriginStorageLevel only decides where the data is. As shown in example above, CacheStorage data is partitioned no matter it is Basic or Standard.

CacheStorage is not "cache", as its lifetime should be controlled by web clients (https://w3c.github.io/ServiceWorker/#cache-lifetimes), like IndexedDB.

For the other real cache types (e.g. http cache), we currently have no plan to move them. It might make sense to have another [General Cache] directory in parallel with [General] if we are going to do this.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230201/060fd915/attachment.htm>