Switch settings backend

[GoogleCodeExporter]

Describe the feature you want implemented.
Use an embedded database to store application settings instead of the built in 
XML based storage provided by .NET.

Describe why you think that this feature is needed.
It could make the reading/writing of settings faster (which makes startup 
faster). It may also shrink the size of the settings file.

Do you have any suggestions on how we could implement, design or present
this feature in an easy and intuitive way?
We could either go with NoSQL (like HamsterDB) or SQLite, depending on which 
suits our needs better.

Original issue reported on code.google.com by ephracis on 25 Mar 2013 at 3:03

[GoogleCodeExporter]

I would imagine we probably want to go with a NoSQL backend. Most of what the 
storage will likely be simple key/value pairs. This means there is a lot of the 
machinery in SQLite like supporting transactions/rollback that we don't really 
need and will ultimately slow stuff down a little bit.

Original comment by zeigl...@gmail.com on 25 Mar 2013 at 10:13

[GoogleCodeExporter]

True, but I figured since over 90% of the data in the settings file is the 
collection of tracks (at least in my case) there should be some benefits to 
having an SQL schema with good indexing. Question is whether those benefits are 
enough. As you mentioned, almost all other settings are key/value pairs where 
the structure of the value can sometimes be quite complex (see Playlist or 
KeyboardShortcutProfile).

Original comment by ephracis on 26 Mar 2013 at 8:56

[GoogleCodeExporter]

I think  this is a case where we might want to maintain a SQLite track/playlist 
store and a HamsterDB settings backend. I guess profiles could be kind of 
complex, but I would image you can decompose those into named pairs of 
actions+shortcut keys.
Keeping tracks may not be completely necessary as we can leverage the windows 
libraries to get track lists from the music folder and if I remember correctly, 
its possible to programmatically manipulate what folders are in that library.

Original comment by zeigl...@gmail.com on 26 Mar 2013 at 1:22

[GoogleCodeExporter]

On that note, since it will affect so much, I will probably branch and start 
tinkering.

Original comment by zeigl...@gmail.com on 27 Mar 2013 at 11:30

[GoogleCodeExporter]

Yes, the profile settings are pretty much just that, plus a name for the 
profile and each profile has a bool whether or not the shortcut is global (can 
be invoked when Stoffi doesn't have focus).

I think we should keep tracks cached as a) it's slow to scan the filesystem and 
b) we keep info not in the files (album art, soon also sound analysis stuff).

When you branch could you create a personal folder under /branches and keep 
your branches there?

Original comment by christof...@stoffiplayer.com on 28 Mar 2013 at 2:19

[GoogleCodeExporter]

This issue was closed by revision r1907.

Original comment by christof...@stoffiplayer.com on 3 Nov 2013 at 7:47

• Changed state: Fixed