Storage Relationships (was Block Level API)

I was on a cell phone and the post was very short - probably not clear
enough... I'm going to continue it here just so I don't pollute the other
thread and sidetrack... If there are bits to merge back in, we can do that
- but I'm not sure that this attempt will be much clearer :-|

Basically what I was trying to say is that:

File seems like a pretty low level thing - I think we need it and that it
is overdue...  I like the way that is shaping up and I see no reason to try
to "avoid" it and leave it up to developers to create an abstraction on
something existing or to prevent it by continuing to add primitives until
we reach 1's and 0's.  But does feel a little like maybe there is something
kinda fundamental here which might be applicable to explaining a lot...

A David Bruant mentioned in the other thread[1] the way Tizen groups three
major kinds of storage seems kind of logical... Imagining we had them all
today in their final form a few questions come to mind:

It seems that as "areas of storage in the browser" there are shared/common
concerns about limits, security, locking, whether they are 'session' or
'persistent', etc which could maybe be further explained so that what you
learn in one part is easily transferable knowledge and additional forms in
the future can hopefully follow and could potentially answer questions
about what is "down there" for a lot of things in the web platform now.

For example:  Without getting too deep:  What is backing Cache?  It seems
to me that it *must* involve File... But a different storage location? And
maybe not *just* file but probably some kind of store more like IDB for
querying metadata... But a just different storage location?  It feels like
it would be nice to get some quick sketches about how some of these
concepts fit and relate to make sure that we are getting good/useful
primitives not just for a particular case, but for the larger goal of
explaining the magic at a low level.


-- 
Brian Kardell :: @briankardell