Add 'atime' to 'dmedia/file' records?

As discussed in comment #2 in lp:680467, we should track dmedia file access, perhaps by adding an 'atime' attribute to the 'dmedia/file' records. First, some background on why we want to track file access...

dmedia is design around some key assumptions:

  1) you have multiple devices

  2) when it comes to media files, you both create and consume prodigious volumes

  3) you want to be able to access any media file from any device in the quickest, most reliable way

  4) the internet is only sometimes quick, and is reliable even less often

  5) cellular data service is never quick, and never ever reliable, not even a tiny bit

The route to a good user experience is having the files available locally whenever possible. Of course, they wont all fit locally, so dmedia needs to do it's best to guess correctly. When you need a file *now* and it's not available locally, we brave the internet (or lan) and get it. But that's playing roulette. So we want to guess correctly as often as possible and have the file already available before you use it.

From dmedia's perspective, your hard drive should always be full... that gives you the best chance of having a needed file. But it also must be full of the right files. For files that have a low probability of being used... they should deleted to make room for files with a higher probability of use. Don't tell dmedia, but your hard drive will also be used for other things, so it might need to delete files stored in dmedia to free up space for "the others". Again, dmedia should delete starting with the files with the lowest probability of being used.

Ah, and dmedia needs to handle user-generated {'origin': 'user'} files specially... in addition to considering probability for use, dmedia can only automatically delete user files when the file is already stored with sufficient durability elsewhere.

'atime' could help, but a running log of all access would give us the data needed to make the best guesses (thought about this more since making 'atime' comment in lp:680467). If doing a running log like this, we wouldn't want to modify the 'dmedia/file' docs themselves, but instead create a document for each access... and probably store them in a separate 'dmedia_access' DB or some such.

Thoughts?

I decided I'm going to tag any bugs related to the larger prediction problem with "prediction".