New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Look at splitting out library / storage from backends. #397

Open
adamcik opened this Issue Apr 6, 2013 · 4 comments

Comments

2 participants
@adamcik
Member

adamcik commented Apr 6, 2013

As discussed on IRC we should be looking at how to start splitting the storage of playlists and storage of output from the scanner in plugable units that are not part of a backend.

For instance the scanner should not be strictly tied to creating tag caches, but simply produce track instances that are feed to any extensions that have Storage/Libraries that can be updated.

@adamcik

This comment has been minimized.

Member

adamcik commented Apr 29, 2013

My current idea for how to do this is:

  1. On a per uri scheme level ensure that there is only a single library, playlists, playback provider. I.e. allow for multiple extensions with same uri scheme as long as the sub components are unique.
  2. Move the tag cache code out of local and into a tagcache extension.
  3. Move the playlists out of local and into a playlistsfolder extension.

Making mopidy scan work with this is a related but slightly different issue, so leaving it outside of this bug. Doing it this way should require minimal changes in our API for now.

@jodal

This comment has been minimized.

Member

jodal commented Apr 29, 2013

I want to get rid of the Backend class and just have independent library/playlist/playback providers, but it isn't entirely straight forward. Today the backend instances serve three purposes:

  1. It has the uri_schemes field, which we can move down to each provider, ref. your first bullet.
  2. The backend instances are a convenient place to share service endpoints, like the SpotifySessionManager.
  3. It gives e.g. a playlist provider access to the matching library so that it can lookup the tracks it needs to make its playlists. If the providers don't share the backend instance, they will probably need access to core instead. Though, there are good reasons for letting providers access core anyway for other use cases. On the other side, allowing the providers access to core breaks the layers and is the path to deadlocks.
@adamcik

This comment has been minimized.

Member

adamcik commented Apr 29, 2013

Mhm, your points nicely sum up the reason why I suggested my simpler approach for now. I'm by no means against moving towards a true split in the longer term, it just seems easier to do this by starting with smaller steps.

@jodal jodal closed this Apr 29, 2013

@jodal jodal reopened this Apr 29, 2013

@adamcik adamcik referenced this issue Nov 27, 2013

Merged

Switch to json based library for local. #595

6 of 7 tasks complete

@jodal jodal added this to the Core cleanup milestone Jun 22, 2014

@adamcik

This comment has been minimized.

Member

adamcik commented Feb 25, 2015

Do we still want to do any of this, do we need a bug for it, or should we close it and move this to the 1.0 doc instead?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment