Caching

[vixalien]

I have a vision to cache as much stuff as possible for a very efficient navigation experience.

Navigation Caching

By default, Muzika will cache all details pertaining to data as the user navigates. The data that will be cached will include, but not limited to:

• Tracks
• Artists (probably not necessary)
• Albums
• Playlists

As soon as a user navigates to an item or plays a track, it will be cached in the local cache.

No stale-while-revalidate

Contrary to my initial thoughts, I think it's best if we don't use a "stale while revalidate" approach. Essentially, this would mean showing the old (stale) data from our cache to the user, while we make a network request (or many), then show the latest data. This approach is good because most data will not change that often (talking about albums, tracks) but it will introduce jank and unnecessary hydration (double renders).

Instead, we will save the data in the cache, and only show the data when the user is offline. This will put us on track to provide Download support, as we will have most information in the cache.

Manually initiating a cache

The user may also be able to request that cached data be downloaded/updated manually, by initiating a download of an album or playlist.

Database

I think using TinySPARQL is very convenient for this. This is because the database is small, portable, and requires no migrations. Besides, it already has the Nepomuk MultiMedia (NMM) ontology and the Nepomuk File Ontology (NFO). This means we won't really need to implement much of the schema.

Eviction

We need to have a way to evict the data from the cache. We can write a simple LRU Cache implementation on top of the database, to ensure that the cache doesn't blow out of proportion. In the future, downloaded data will have priority and cannot be evicted, unless the user manually removes the download.

Singular representation

To use the cache correctly, we will need a unified model to represent different types of data. For example, we will need a single representation to store a Track. Currently, we have different types from libmuse: PlaylistItem, SearchSong, ParsedSong, Song, QueueItem and more.

Grilo

My first thought is using Grilo because it allows us to have a nice representation of media files, and their containers (albums, playlists) etc. With this library, we can easily normalise the various data we get from libmuse (PlaylistItem, SearchSong, etc...) to a Grl.Media, and then request additional data we need, like uris, lyrics, etc..

Roll our own

If Grilo is assumed to be too limiting, we can roll our own implementation for singular representation of data. This will be hard, but not impossible.

The Framework

Here's what it would like (sorry for my less-than-ideal design skills)

graph TD;
  Application([Muzika]);

  CacheResolver;
  NetworkResolver;

  subgraph Stored Data;
    DatabaseResolver;
    Database[(SPARQL Database)];
    DatabaseResolver -.-> Database;
  end

  NetworkResolver -.-> libmuse[/libmuse\];

  CacheResolver --> NetworkResolver;
  CacheResolver <--> DatabaseResolver;

  DownloadsResolver --> DatabaseResolver;

  MediaResolver --> CacheResolver;
  MediaResolver --> DownloadsResolver;

  Application --> MediaResolver;

Loading

Media

Each Resolver will interact with Media . See Grl.Media. Basically this is a representation of either a media item, or a container.

A Resolver will simply be an implementation of a Grl.Plugin.

• search
• resolve: get more metadata (basically properties) about a media

these are only really useful for the network resolvers

• browse
• query return certain structured data based on a specific format. For example, get artist albums

the following are only really useful for the cache/download resolvers:

• store: store a media item
• remove: not all resolvers can remove items.

The MediaResolver will mix and match the results of each child resolver, based on the status of the Network and what the user wants™.